Users Do Not Appear to be Logged Out After Password Reset

Problem statement

While resetting a user’s password does make their Auth0 session expire on the server as per our docs here, you may find that users appear to still be logged in after completing a password reset. Why might this be?


Resetting a user’s password makes their session expire on the Auth0 server side, but note that there are different session layers:

Sessions and invalidating Auth0 session layer does not mean invalidation of your Application session layer. Your application would need to clear the local application session, a different browser would have it’s own local session via cookies for example.

In terms of invalidating all sessions, we do not currently provide this functionality out of the box (there is a Session Management API on the roadmap) but there are a couple of steps you can take and we briefly document your options here:

i.e. keeping token (access and refresh token) along with local application session lifetimes short. This way when the application goes out to the server to renew an access token for example and see’s there’s no session on the server (due to the password change) the user would need to re-authenticate.


It may be that there is an application session associated with your application. Although the logout endpoint clears the Auth0 session, the application level session may still be present and this would also need to be cleared as part of the logout process. Some of our SDK’s may handle this for you so it’s best to check the documentation for the relevant SDK as to what logout actions should be taken. You can also review this document for information

The video here explains logout quite well.

If you are using Refresh tokens, again you can keep the refresh token expiry short (but longer than access token expiry). If you reset the user password, the user will continue to be able to get new access tokens given the current refresh token is still valid until the refresh token expires and has to make a call back to Auth0 at which point the user would need to re-authenticate.

This can be expedited as the refresh token can be revoked but you tend to need the id of the current refresh token as per the docs here:

and this could be implemented via the post change password action as well:

You could also revoke the grant instead if the refresh token is unknown, deleting the grant by user_id could be an easier option:

and can also be executed via the Post Change Password Action.