Not getting user info when authenticating a user anymore

Help
,
1

I’m having trouble getting the user’s information when authenticating a user.
The scope we are using is: ‘openid profile email roles groups permissions’.
This was working before. We are not getting nickname, email info, name and picture anymore.
Is there something that has changed in the API and we should make some change in the code? Or maybe you have any other suggestion?

UPDATE

This is the request that we are making:

https://test-domain.eu.auth0.com/login?client=JekdM7wJ1kzvT0JfqeXeMUywQpT36A6T&protocol=oauth2&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback&response_type=token%20id_token&scope=openid%20profile%20email%20roles%20groups%20permissions&audience=https%3A%2F%2Fwww.biobank.ie&nonce=tULKaje_AR.sCT1hVcDFYTKpq8Mk3Ouy&auth0Client=eyJuYW1lIjoiYXV0aDAuanMiLCJ2ZXJzaW9uIjoiOC45LjMifQ%3D%3D&state=mu4C8tJDWRG9hiJNTooVq_ebYXWGruM3

This was working before and we were getting the information that we needed and suddenly it stopped working. No matter which scope we send we are getting the same response, like the scope is not affecting the response at all. If we send an empty scope, we are still getting the same. I checked in raw json and we have those attributes set. This is what we are getting when we decode the access token:

{
  "iss": "https://test-domain.eu.auth0.com/",
  "sub": "auth0|5989cfcb2171484ba580ee02",
  "aud": "JekdM7wJ1kzvT0JfqeXeMUywQpT36A6T",
  "iat": 1507627377,
  "exp": 1507663377,
  "at_hash": "VUEbpReJsdDElZw6hK6uFw",
  "nonce": "okQCY2pqAtKNE1lRI.V86w6YfkM1ZX0k"
}
2

The only suspicious thing associated with the scope you’re requesting is that roles, groups and permissions are not standard OIDC scopes and assuming they are not associated with a custom API then they are being included as a way to include that information in the generated ID token; if this assumption is correct then technically that part will only work on legacy flows as the latest authentication endpoints strictly conform to the OIDC spec.

Having said that, the particular situation around non-standard scopes should not be relevant here as you complain about not receiving information about nickname, name and picture which are attributes covered by the standard OIDC profile scope and also email address information which is covered by the also standard email scope. In addition, you’re also including the openid scope to signal the transaction should be treated as an OIDC request so unless the end-user does not have those attributes set you should be receiving this information.

I additionally performed a quick test with an end-user that had those attributes set (you can double-check the Raw JSON tab when viewing the user profile in the dashboard to be sure the attributes are set for your test user) and performed an authentication with scope=openid+profile+email which correctly returned the information.

In conclusion, if you’re sure the user has the associated information set then update your question with the exact steps endpoints called in order to reproduce the situation.

In relation to your update one thing that caught my attention is the endpoint associated with your posted URL (https://[your_domain].eu.auth0.com/login). In general you should be performing the request against /authorize, however, you may be doing this and just copy pasted not your original URL, but the one to /login. If you can confirm that you are indeed calling /authorize that would be great.

3

I posted an update to my original answer to consider the additional information shared.

4

@jmangelo, we have the exact same problem, that happened at the same exact day the original question was posted.
The exact same fields disappeared and we get an identical response. This was working perfectly before, and I find it suspicious that this happened at around the same time as this post.
I double checked, we are using the correct scopes, and the end-users have those attributes.
We are using WebAuth.

5

@jmangelo Yes, we are using /authorize. We are also using WebAuth.

6

@jmangelo, we have the exact same problem, that happened at the same exact day the original question was posted.
The exact same fields disappeared and we get an identical response. This was working perfectly before, and I find it suspicious that this happened at around the same time as this post.
I double checked, we are using the correct scopes, and the end-users have those attributes.
We are using WebAuth.

7

@jmangelo Yes, we are using /authorize. We are also using WebAuth.

8

@zaid.hamzeh or @stasa.aleksic can either/both of you capture an HAR file and then share it? Be sure to remove any information you deem sensitive and you can also zip with a password and share the password through sharelock.io to email domains ending with @auth0.com. The reason I ask is that I cannot reproduce the issue and as such an HAR file could help pinpoint the issue.

9

@jmangelo I’ve attached a HAR of the issue.
Here’s the sharelock link:
https://sharelock.io/1/mY0ZyLWzWmcnnmNiBvTWIv0eIeZGIjAWK6HrWzx_DsY.0SJ5Qx/bOnGZyXrxZNHVD_adEFsSXa2CrFwmvUdYovLX5FMVBxQuUikbb/QI7eQB0InY-oqAfkIiq835RZ7sdUgV1bqNC83Kxh3B9ffMQ.zr/JCx7WBpZufzxPo5KXijA

[link text][1]

10

Thanks for providing this, the request data all seems good and similar to what I was using for testing. As mentioned before including roles groups permissions in the scope is a noop and can be removed, however, the email and available profile information should be retrieved so I’m without leads… That HAR file seems to come from Chrome which seems to have the habit of not exporting response bodies so I was only able to analyse the requests… if you want to capture a trace with something else (like Fiddler) I will happily look into it as this is really intriguing.

11

@jmangelo I’ve attached an updated capture with FiddlerCap.
Does that contain the info you need?
https://sharelock.io/1/b676xINJt8KFupBXCTDjGCYEPoql7BpSFeXaiEm5zJU.40lkLN/VjgnZziYc6n-37wobi6us_aKnPx3h8okNDFEkTxHpil9xm9D9f/qKCnXacj5gsvMe5hfxi2IyWU_n873EwERg9lpoSUdosbj7A.ht/32B1fndYxfUDYpIZSviA

[link text][1]

12

Thanks for doing that, however, by default Fiddler will not capture HTTPS traffic unless you configure it to do and the configuration implies trusting a self-signed certificate and also means it would intercept most HTTPS traffic. If you understand the implications or are able to do it within a development virtual machine then that would be great as the capture you provided only contains the portion on the flow happening on HTTP and all endpoints in Auth0 use HTTPS so there’s actually no relevant data to troubleshoot.

13

@jmangelo Sorry, I didn’t notice it hadn’t captured the HTTPS traffic. I’ve redone and looks to contain more detail now.
https://sharelock.io/1/AEEfxQf5wOpA_WXEzTFIFSAdyusbHvml2dIcR6Fujm4.xDJJOL/3NpAI0UNAOiRr7nnNWg-Jy19H6vIw8tWbHhayGQFNtXyWMrwUY/cpR8mJJ89kw7KonHwKNtomc_YKvOfxWy1IkVIYx0La0ahys.eW/1yM7ywZm9NQcZrCW-vhg
[link text][1]

14

@david3 thanks for that, I was able to look at the response of the /usernamepassword/login endpoint which in this the case is the last step before redirecting to the client application. If you see the HTTP redirect you’ll notice that the authentication response contains a scope parameter listing all the scopes that were actually granted. You’re requesting email and profile scope, but then you likely have a rule doing context.accessToken.scope = ...] and you’re only granting the API scopes and not the user information scopes also requested.