I’m currently implementing the PHP sdk, I have some questions about when I should be invalidating user sessions. On parts of the docs site it talks about sessions requiring re-login when certain events happen, and I assume the session is invalidated on auth0’s side. I’m not sure how to check if that session is still valid?
The behaviour I ideally want is preventing simultaneous login from more than one device at a time - I can do this in my own solution but ideally I’d use auth0 in some way, I sort of expected it to have that functionality
At present, we don’t have any functionality for checking if an existing session has been invalidated server-side. We also don’t presently have any built-in functionality for restricting user contexts to single-session instances.
For SDK usage, sessions should be thought of as stateless since they’re stored client-side. After they’re verified, validated, and stored on the end-user device by the SDK, they are considered valid until they expire. This makes SDK integration very simple but also means certain scenarios, such as the one you’re describing, are a little trickier to address. Purely using the SDK, you’d only see that a session was invalidated server-side if you attempted to make an API call to a protected Auth0 endpoint using the authenticated session’s access token, which would raise a network exception.
We do have a few things on our radar that may help with this in the near future, but at the moment, you’d really need to build this out within your application logic, I’m afraid.
You could implement a session-revoking mechanism within your application logic that limits a particular user context to a single session. When returning to your application after authentication (at the ‘callback route’), you could capture the relevant details from the authenticated user, such as the unique identifier for the user. You could store this as a simple key-value store, using the unique identifier as the key and the access key as the value. Then, on each network request to your application, check that key-value store against the authenticated session and see if it’s the currently stored access token for that user. If it isn’t, invalidate the old session (the clear() method). Obviously, this approach isn’t perfect, and it means adding an extra request to some sort of persistent key-value store on each request, but it’s probably the best path for now.
Stay tuned to future SDK updates, as we do have much better ways of managing this planned — but I can’t offer details or a timeline on those changes at this moment.
