• Developers

  • OAuth returning private information when creating a session

I was just testing the new OAuth API and I noticed that it seems to be returning the wrong information.

When you create a session with the received access_token it returns a new user type which is pretty normal considering it is a new type of connection. The weird thing however is that the granted_by_user key, which should contain the detailed information on the user is nearly empty and only contains the user's display name and avatar.

Whereas the requested_by_user key is completely filled with user information. Now I'm not going to share a direct copy of this info since it contains some private information but it is the same response you'd get when requesting your own user information from the API.

Some of the information that is returned includes the following details about person providing the OAuth client:
- billing contract details,
- home address
- id-card information
- phone and email details

What I'm guessing that is going on is that the API has switched which info is returned. To clarify, I would expect that the user who is giving permission through OAuth sees the developer's name and image so he/she knows who is getting access. And then the granted_by_user field should contain detailed information on the user's own account. Right now this seems to be swapped around? 😅

This is making the OAuth API unusable for me since anyone using my desktop application could see all that private information about me.

    I almost forgot to mention, we did test if the API key was giving access to the developer's accounts for example but that doesn't seem to be the case. So it is purely the amount of information that is being returned which is mixed up

      Good morning @Gregory#27751 !👋🏻

      Thanks a lot for reporting and explaining the issue so clearly!

      It looks like a bug, so i attach the "bug"-tag to this topic.🐛

      I expect it to be fixed quickly by the bunq development team. 👍🏻

      Have a great weekend!

      Cheers,
      Bastiaan

        @Gregory#27751
        Hey Gregory 👋

        Thanks for posting about this, but it is working as intended. Lets say I'm Moneyca, and am requesting access to your account. After you've approved this request Moneyca gets the access_token which will allow them to access your account. After calling the session-server (or user) endpoint, you will indeed get a new type of user UserApiKey. This user itself holds two other users requested_by_user (Moneyca) and granted_by_user (you). As this key is to be used by Moneyca, it does not matter if all information on them is displayed within the requested_by_user as they will already have access to this anyway, and this allows the usage of the normal User object (in the SDKs for example). They also will have access to your public nickname and avatar through the granted_by_user.

        Hope this clears it up a bit. If you have any questions, don't hesitate to ask!

        Have a great weekend and happy coding! 😄

          Okay, please wake me up when this API turns actually useful for devving and distributing mobile apps that can run on the user's device without any server side components.

            @Jordy#27875 The problem is that you're completely blocking off all client-side projects from using OAuth now. It is more common practice to only use the client_secret when using a refresh token to request another access_token without notifying the user.

            And besides that I still don't understand why you would give such detailed information about the developer. When my application gets access to the user's account I don't need my own information to do things for the user. It makes much more sense to receive the user's information right away like with a regular API key login instead of forcing me to do a request to the /user endpoint.

              It seems to me that the API as is allows for quite some neat use cases be applied, but it still falls short of amazing use cases, eg because of this OAuth issue (ehm... feature, that is). Not sure the sharing in read only mode is still there, but indeed better be able to allow apps to read only account info, and not have full control on the end user funds. Bunq is onto something with the approach, just not quite there, IMHO.
              Please bunq, help the devs, help your users :)

                @Gregory#27884 We only support the Grant type Authorization Code, which is meant for server side use, in which the User (resource owner) never gets access to the API key (access token). I do understand your use case which corresponds to the Implicit Grant type. We always like to get feedback from our users, and will look into the possibly of implementing this in the future.

                Hope this explains the behavior a bit.

                Also see https://tools.ietf.org/html/rfc6749#section-1.3 for the different Grant types and their uses.

                  9 days later

                  @Jordy#27895 I'm stumbling upon this issue as well. I've implemented the whole OAuth2 authentication in Swift, but now my information is send to the app. When I use a server between the app and bunq, I am between the user and bunq. I don't think bunq wants those developers to be the risk factor. If my server is poorly secured, the users are the victims.

                  I really can't find the right way to implement a connection to bunq, can you tell me what bunq wants the developers to do? It's a trade off between sharing my private data with my users, or the users sharing their private data with me. I don't want to have access to my users, I don't want to see their data. For now, I can't decide.

                    @MarcoS#29647 Right now you could use the regular way of using API keys and then do everything within your app. That'd still mean the users would have to trust you with giving you access ofcourse.

                    So there is still no real trustless way to do anything more than fetching info/doing payments using the Connect requests.

                    And @Jordy#27895 I understand that you are following the Authorization Code spec (I still don't see a valid reason why you would send so much private information about the developer though).
                    It is just frustrating for me that after waiting for months for a OAuth2 implementation that it has a bunch of issues and quirks. And then on top of that, it is quite litteraly unusable for my own project and any other project where the developer doesn't want to store user data on a server.

                      Asking people to enter their API key in my app is indeed the only way I can make sure I don’t have to handle their data with care. But OAuth was introduced to overcome the hassle right? For now I will develop a temporary server between the app and bunq to filter my personal information from being send to the app. In the case of Gregory this is not a possible solution.

                        Write a Reply...