Auth0 returns a stale userInfo

[georgii.rychko]

This issue is very similar to

Check if email_verified without signing in again.

I’m currently using the v8 version of auth0.js I’m successfully able to find out if the user’s email is verified with this call function getUserInfo() { var deferred = $q.defer(); accessToken = localStorage.getItem('accessToken'); webAuth.client.userInfo(accessToken, function(err, userInfo) { if (err) { deferred.reject('Can not get user info'); } else { userInfo = userInfo; deferred.resolve(userInfo); } }); With this inf…

and

Calling user info endpoint returns stale information for email verified attribute

I’m using Auth0.js to call signupAndAuthorize, effectively storing an access_token in localStorage and calling the HTTP API directly (not through Auth0.js) at /userinfo to get the email_verified value for the user. I keep doing that every time the app starts. When I tried verifying the email though, I see it as true on the Raw JSON part of the Dashboard, but the calls to /userinfo keep returning email_verified=false! This happens until I login again, then I get it as true. Why?

Here is my use case:

1. A user changes its profile
2. Changes get sent to Auth0 using Auth0 Management API v2
3. Then I reload my SPA
4. SPA fetches data from the userInfo endpoint using token stored in local storage
5. userInfo response contains stale data (the one that existed before the user was patched)
6. Though when I go to Users section (in Auth0 admin panel) - the user I’ve patched has the latest changes.

In my case, the userInfo object has a metadata section which contains user’s lastname and firstname. And this is the section which has a stale data when accessing it using the userInfo endpoint.

[Carlos_Mostek]

This is intentional behavior. The /userinfo endpoint contains information about the last authentication. You will not get new information until the next authentication request.

[Carlos_Mostek]

One other thing you can do is use the Management API to get new user information. To do this you would have to proxy the call to the management API through your own API so that you can use client credentials to get a Management API token to get the data about the user that is the latest.

[georgii.rychko]

Now it is clear. I guess it would be very convenient to say about this behavior explicitly in the docs.

[georgii.rychko]

Thanks for the Management API advice!

[andrej.developer]

What is then the “intention” purpose of this endpoint? Why would anyone call this endpoint, if not to get current user profile? (at the time of authentication we can get user information in claims don’t need another call)

• If this endpoint returns “information about last authentication” it should not be called “userinfo” (misleading name)
• None of this “intent” or use is even mentioned in documentation that states:

to obtain the user’s profile

• suggestion to get the actual user profile through 2 hoops of API/Management API instead of single call to the source of information is cumbersome at best.

[Carlos_Mostek]

I hear what you are saying :). /userinfo does seem like a pointless endpoint because it generally is. There are few cases where it is necessary. It exists because it is part of the OIDC specification, but the fact is that 99% of the time it is better to just grab the information from claims inside the ID token and save yourself an extra API call entirely.

The Auth0 behavior for this endpoint exists because you can set custom claims that are defined when you run rules. Rules only run as part of generating new tokens. Since the information from /userinfo must match the information in the ID token, the only way to generate those custom values would be to run rules again. So, if you want to update /userinfo, you need to call /authorize again to refresh the authentication session.

All that being said, you also make a great point about this needing clarification on our docs page. I’ll send this over to the docs team.