Calling /userinfo returns empty object on subsequent logins

It appears that if a user goes back into my application, which redirects the user to Auth0, if the user had previously successfully logged into Auth0 (for my app) they don’t get prompted for any credentials and immediately get sent to the callback URL. This is fine, except that a new access token is sent to my app, which when used with /userinfo returns a status code of 200, but an empty object instead of an object populated with the user name, email, etc. So my app has no idea at this point who the user is. This happens unless browser cookies are cleared.

Example:
Initial access to my app, user gets redirected to:
https://[my-domain].auth0.com/authorize?response_type=token&client_id=[my_client_id]&redirect_uri=https://[my-app-url]&state=[random]

Client app then gets called, with the url appended:
#access_token=[access token 1]&…&token_type=Bearer

So, if I call:
curl --request GET --url ‘https://[my-domain].auth0.com/userinfo’ --header ‘authorization: Bearer [access token 1]’ --header ‘Content-type: application/json’

I get the expected JSON object output. However, if the user later on goes back into the app, without the “#access_token…” appended to the URL, a fresh redirect back to auth0 happens, a callback back to my app URL happens, but I get a new token [access token 2]. When using that new access token, on a GET to /userinfo, I get HTTPS status code 200 (same as the first time), but the results are just {}.

The amount of information returned by the user information endpoint is in general a direct consequence of the scopes the client application requested when initiating the login. There are some possible exceptions, but lets ignore them here.

The URL you provided as being the one where the user is redirected (/authorize) is where the login is initiated and there’s no scope parameter in the example you provided which is immediately interesting. Although a definitive response would require analysis of the network trace for both scenarios (initial one and when the user later goes back to application) one possible suggestion to try based on the information you provided would be to ensure that any login request started by your application is explicit (includes) the scope parameter with the required values.

For example, scope=openid+email should at least return a user identifier and email information from the user information endpoint (assuming the scopes requested are indeed issued).

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.