User is Not Logged Out after Password Reset
Sep 10, 2025
Overview
While resetting a user's password makes their Auth0 session expire on the server, as per this document, there still might be situations in which the users appear to still be logged in after completing a password reset. This article explains why this might be.
Applies To
- User Session
- Password Reset
Cause
and invalidating the Auth0 session layer does not mean invalidation of the Application session layer. The application would need to clear the local application session; a different browser would have its own local session via cookies, for example.
In terms of invalidating all sessions, this functionality is not currently provided out of the box (there is a Session Management API on the roadmap), but there are a couple of steps that can be taken. This document briefly covers the available options, 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 sees there's no session on the server (due to the password change), the user would need to re-authenticate.
Solution
Those who want to kill the application session layer after password reset events might find the OIDC Back-Channel Logout feature helpful. This feature lets applications subscribe to session termination events, like password change, and then terminate the application session layer. Please review this document for more details. Here are the more general documents on how this feature works.
If Refresh tokens are used, it is possible to keep the refresh token expiry short (but longer than the access token expiry). If the user password is reset, 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 the ID of the current refresh token will be needed, as per this document, and this could be implemented via the post-change password action as well. Please see Invalidate the user's session in another system.
It is also possible to 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.