Silent Auth errors with Login Required after updating app_metadata via Management API

Hello,

I am trying to understand why calling getAccessTokenSilently redirects me back to the login page after I update my user’s app_metadata via the Management API.

Here’s my setup:

  1. I have two applications: 1) an SPA, and 2) a M2M
  2. The SPA shows the Auth0 login screen and upon successful signup/login redirects back to my application
  3. After redirecting, the user is requested to enter an invite code (from their email) to link the Auth0 user to my backend domain model
  4. The SPA invokes my backend with the invite code. The backend uses the M2M client credentials to call the Management API to enhance the logged-in user’s app_metadata with a linking id
  5. I also have a Rule defined which upon login/silent-auth will append the app_metadata as a custom claim in the new access token
  6. After the backend call completes, the SPA requests a new access token via silent-auth. This is so that all subsequent backend calls will be made with a new token that contains the custom claim.

The issue I am facing is that when requesting a new token via silent-auth (after the backend call), the SPA gets a “login required” error and gets redirected back to the Auth0 login page.

Now what’s odd is that if I update the user’s app_metadata directly in Auth0 and then have the SPA request a new access token, it’s all hunky dory. But if I update the same user via the Management API, a request for a new token fails and requires a re-login.

Is there a difference in the way Auth0 handles updating a user directly from the Auth0 UI vs the Management API? Why does silent-auth work just fine in the former case, but does not work in the latter case?

I feel like I am missing something fundamental. Any help here would be much appreciated.

Thanks!

If it helps, here’s a sequence diagram of my registration flow:

Any suggestions here? The difference in behavior of silent-auth (when updating app_metadata via the Management API vs updating via the UI) is quite puzzling.

The UX of of having to re-login is what I am trying to avoid.

Thanks!

Hi,

Is your backend updating the email or email_verified attributes when it patches the user?
Patching Email or Email_verified via the management API will invalidate the Auth0 session.

Example:

This post body will invalidate the session:

{
  "email_verified": true,
  "app_metadata": {
          "TestData": "TestValue"
        }
}

This one works without invalidating the session:

{
  "app_metadata": {
          "TestData": "TestValue"
        }
}
2 Likes

Yes, my backend was setting email_verified: true. After removing it, my frontend is able to refresh the token silently without getting the login required error.

Thanks Marcus!

Would you mind explaining why toggling email_verified invalidates the session? Is this shared in the docs anywhere?

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