Backendless making two different requests to user info OAuth endpoint with different tokens

User Service
1

I am building a custom OAuth service for my app, and everything seems to work fine except for one issue:
After login is complete and the auth code is exchanged for a token, I get two different requests to the user endpoint. The first one uses the bearer token I provided in my OAuth service, while the second one uses a bearer token that is a GUID (that changes every time and does not match any data I can see in the database). My OAuth service does not issue any tokens that are in GUID format, so I am not sure why two different requests are being made to the user info endpoint.

2

It appears that when redirecting back to my app after successfully authorizing with OAuth, it passes a GUID as the user token, rather than the value provided by my OAuth service.

3

Hi Jacob,

Welcome to the Backendless community!

Could you please clarify if you are using our SDK to integrate with your OAuth service? If so, which one?

Regards,
Mark

4

Yes, I am using the SDK. Specifically the JS SDK. This is my logic at the moment (this is a proof-of-concept, not intended to be production code):

const searchParams = new URLSearchParams(window.location.search);
const code = searchParams.get('login');

if (searchParams.has('login')) {
  Backendless.UserService.getAuthorizationUrlLink('OTASsoTest')
    .then(oauthLoginUrl => {
      window.location.href = oauthLoginUrl;
    })
    .catch(err => {
      debugger;
    })
} else if (searchParams.has('userToken')) {
  const token = searchParams.get('userToken');
  const userId = searchParams.get('userId');

  debugger;
  Backendless.UserService.loginWithOauth2('OTASsoTest', token ?? '')
    .then(res => {
      debugger;
    })
    .catch(err => {
      debugger;
    })
}

The idea is that you go to ?login to trigger a login, then it will read the parameters from the query string if available.

Having traced through this, the step that seems to be causing trouble is that after the step where the user is redirected to the Backendless authorization (api/users/oauth/OTASsoTest/authorize) and then auth code is exchanged for a token, the user is redirect to the redirect URL with ?userToken=GUID where the GUID is coming from an unknown source rather than being the token passed back by my OAuth server.

5

Do I understand correctly that the else if part of the code is executed after the redirect? I am struggling a bit with understanding when and on what page each part of the code is being executed.

6

Yes. Here is the flow:

  1. The first “if” (searchParams.has('login')) is fired, redirecting the user to the login page (on my OAuth service)
  2. The user logs in to my OAuth service
  3. The user is redirected to the redirect URL provided by Backendless with the auth code
  4. Backendless exchanges the auth code for a token
  5. Backendless redirects the user back to the same page as the original, but with the user ID and token in the query string, executing the “else if” portion (searchParams.has('userToken'))

Step 5 is the problematic one, since the value passed in the userToken query string parameter is a GUID of unknown origin, rather than the token provided by my OAuth service.

7

Thank you for the clarification. @Andriy_Konoz, could you please check this issue?

8

@mark-piller , @Jacob_Goldberg

This is an expected behavior. Token from your OAuth service is used only during login to retrieve user basic info. At the end of the login Backendless auth token is issued for user. This token you saw at the step #5 in userToken param. Backendless API recognizes only its own auth token.

If you need auth token from your OAuth service on the client, you need to use different approach for login. This approach is described here. The main point here is that you perform login of user via your OAuth service completely on the client side and then use access token from OAuth service to login user in Backendless via this SDK method.

Regards, Andriy

9

Thank you for your assistance. By following the process to do this completely client-side that did the trick.