Auth0 layer session management

Hi there, I have a question around how sessions are managed at the auth0 layer.

In our application, we persist sessions server side, so we can revoke sessions at the application layer.

Currently the only way someone is able to change their password is via the forgot password link in the universal login.

I have setup a post password change action to call an endpoint in our application layer, to delete all sessions in our application server side session store, using the user_id from the event object. So the next time they try to authorize using an old cookie (our application cookie) they are unauthorized. My understanding was that the auth0 session is invalidated when a password is changed, so we just need to handle our application layer.

What i’m finding is if there are other sessions still active on multiple devices, an unauthorized error is returned from our application, they are then redirected to auth0 to login again, but it seems as though the Auth0 session on another device does not automatically get invalidated at the Auth0 layer when a password is changed, as they hit the authorize endpoint in Auth0 and that is successful without logging in again. They are redirected to the auth0 success callback in our application and a new session established.

How do I ensure that all Auth0 sessions are invalidated at the auth0 layer?

I can see that there is this API to delete all user sessions, but I get this error

[error] API request failed: 403 - {“statusCode”:403,“error”:“Forbidden”,“message”:“Subscription missing entitlement”,“errorCode”:“feature_not_enabled”}

What level of subscription is needed to get that feature enabled? And will that solve my problem?

Alternatively, if I store the auth0 session ids, would the other option be to call the logout endpoint Log Users Out of Auth0 with OIDC Endpoint with each of the session ids and our client id to ensure that all sessions are logged out?

I might be missing something, but this is what I’m finding when testing with multiple devices.

1 Like

I see the same error with GET /api/v2/users/{user_id}/sessions.
My management API access token shows the scopes contains read:users read:sessions delete:sessions

Just following up on this post, I got this wrong, changing the password does invalidate all Auth0 sessions. I’m not sure why I was experiencing the issue where the user was being logged back in. I must have been missing something when testing. I’m wondering if I got something wrong with the api call in the post password change action.

I’ve tested a few times now, and can confirm if a user is logged in to multiple devices/browsers, and they change their password, all auth0 layer sessions are invalidated. Using the post password change action to clear out the sessions in our session store in the Application layer, and redirecting back to the auth0 universal login will result in the user being prompted to login again.

I’m sure this is too late for you but in case someone else hits this from google you need enterprise to use the session api :frowning: it would be nice if that was documented on the api.

To use the Session Management API, you need the Enterprise plan. If you don’t have this plan but want to test the API, you can create a new tenant and get a free trial period.

Hey there, everyone!

I’m excited to inform you about our next Ask Me Anything session in the Forum on Tuesday, July 30, with the Product Management team. If you have questions about upcoming features like FGA, Manage Sessions in Actions, or SCIM. Submit your questions now, and our esteemed product experts will provide written answers on July 30. Can’t wait to see you there!
Learn more here!