Editing user data (first/last name) in SPA forces re-login on refresh

I have a SPA with some custom user-management (via the Auth0 management api) functionality.

The logged-in user (via Username-Password-Authentication connection) can edit their own first or last name (SPA makes calls to our API which updates Auth0).

This seems to work fine - after editing they can go about using the app as normal, token still valid, other API calls (where token is checked) all work fine.

However, if they refresh the page they are kicked out and have to login again (auth0.checkSession does not renew the session when the app loads). This happens regardless of whether or not the edited information (profile) has been included in the token scope.

I’m trying to figure out root cause, and if there is some way I can prevent this from happening. Any ideas what might be causing this or where to investigate further?

Hi @benjaminwfox and welcome to the Auth0 Community!

Have you noticed any errors being returned by the auth0.checkSession when you’ve been debugging this either in the console or elsewhere? Additionally are there any logs that populate in the Auth0 Dashboard that are related to this event?


Hey Colin, thanks for reminding me that the logs exist :smile:

It appears that updating the users name is also triggering the email to be updated (receiving Success Change Email event) even if the email remains unchanged. I suspect our API is sending the entire user payload with the PATCH operation, so will follow up with our team.

I also confirmed that updating the users name alone was not enough to force the user to re-login.

Hopefully that will solve the issue, will follow up on this issue once I confirm.

Thanks again for pointing me in the right direction!

Followup with the eventual solution. There were indeed superfluous email-related fields being sent. These were blocked, verify_email, and email_verified.

With additional testing I found that if the email_verified attribute is present, regardless of whether or not the value has actually changed, it will trigger the “Success Change Email” event and require the user to log in again.

Thanks again!

1 Like

@benjaminwfox way to go with finding the root of that issue! I’m glad you’ve been able to get the correct user behavior moving forward.

Have a good one and thanks for choosing Auth0!


Thanks @benjaminwfox for sharing the fix with the rest of community!