If I login successfully with passwordless with one email address, and then login again with a different email address (without explicitly logging out in between) then I end up being authenticated as the first user, and not the most recent one used.
Is that expected/desired behaviour? It seems somewhat surprising, since I can fully work through a passwordless flow and then find myself authenticated as a completely different user.
Hi @jedrichards. Once you are authenticated you have a valid token. The token has a lifetime attached to it and remains valid until it either expires or you explicitly call the logout endpoint. We have run into the same issue, though not in a passwordless context, where (in our case) one spouse logs into their investments dashboard and then the other spouse tries to do the same using the same device / browser but the first spouse has not logged out and the token is still valid.
@markd Thanks for the extra info, glad to hear it isn’t something I’m doing wrong.
I’m confused why Auth0 handles this this way, since it feels logically to me like a new successful login on a browser should nuke the cookie for any previous sessions.
The answer to that is bit beyond my capabilities, though it may have something to do with the OAuth specs. Just a semi-educated impression on my part but in general OAuth solutions seem to expect “well behaved” clients. E.g., Users who log out when they are done their work (to avoid the problem you are referring to), and absolute trust in a JWT until it times out (JWTs being autonomous, they remain valid even if you, say, delete the user associated with the JWT … keep your JWT timeout low!)
That said, OAuth & OIDC is rapidly evolving and Auth0 tends to move quickly as well. Worth occasionally looking at OAuth 2.0 — OAuth and OpenID Connect | OpenID. Consider joining the mailing lists and browsing the posts occasionally.
It’s curious, because I was previously given some advice by an Auth0 employee (in an unrelated GitHub issue) that is was better to just clear the local app state on user logout, rather than nuking the main Auth0 SSO session and potentially logging them out at the provider from any other applications using the same session.
But if that means the first user to log in gets perma-logged in until their timeout expires then I don’t see any other option but to call the hard logout endpoint.
Hi @jedrichards
The login process has a couple of areas that you have to take into account when planning your session management:
I will assume that you have a simple Single Page App using Universal Login for the purposes of my explanation (there are many possible variations).
During the login to your app, the user will be redirected to the Auth0 Universal Login where they will login using a provided method (e.g. username/password, Google, Microsoft, etc).
Once they complete login Auth0 will create a cookie for SSO purposes on their domain and will redirect the user back to your app with an access_token and id_token which are JWTs.
These tokens specifically have an expiry but they are not tracked and cannot be revoked which is why you are advised to keep the expiry for these tokens low. You as the developer are responsible for how you manage and store these tokens with the recommendation being to store them using the localStorage API (or sessionStorage API depending on your needs).
If you choose to store the tokens in the localStorage then a user’s session in your app will continue to persist until the JWTs expire (even if the open and close their browser multiple times) or until you wipe the JWTs.
The user will also have a session persisted in Auth0 so if you redirect them to Auth0 and they still have a valid SSO cookie then Auth0 will redirect them back to you straight away with new JWTs.
In order to fully logout a user you must clear the JWTs and redirect the user to the Auth0 logout endpoint (as mentioned by @markd). Calling the logout endpoint will not logout the user from the upstream identity provider (unless you provide the federated parameter which is optional).
Hopefully this helps clarify the process a bit! 
@charsleysa Thanks, that’s very useful in clarifying the overall process, and broadly speaking it aligns with my understanding.
Given your explanation, I think my original question still stands - shouldn’t Auth0 clear an existing SSO session cookie from a browser when a new/different user logs in using the same browser? Shouldn’t that be implicitly treated as a logout for the first user, and then a login for a second user?
Doing anything else seems like a pretty glaring security concern, since it could expose confidential information to incoming user. I don’t think it’s enough to assume the client is going to have a chance to do the logout dance/redirect, since it assumes a bullet proof client architecture that is an unreasonable expectation.
Is there a technical reason why an existing SSO session can’t be logged out, when a new user logs in using the same browser?
Hi @jedrichards,
Just an opinion piece: We had the exact same discussion where I work but there are some cases where you just can’t protect users from themselves. I’m not aware of any services that automatically log one user out when another user tries to hit the login page. How would the service even know it was a new user and not just me opening a new tab or browser window? E.g., If I log in to my bank account, and then my Wife takes my laptop and tries to go to the login page for her bank account (same bank), she’ll just be dropped into my account. I need to explicitly log out when I am done. If I contacted my bank about this they would almost certainly just tell me to log out of my account when I am done.