Last Updated: Aug 6, 2024
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
Resetting a user’s password makes their session expire on the Auth0 server side, but note that there are different session layers (please see Sessions)
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
There might be an application session associated with the 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 the SDKs may handle this, so it is best to check the documentation for the relevant SDK as to what logout actions should be taken. Also, review this document for information.
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.