Case:
During authentication, we’re utilizing rules redirect to select a context for that session. That in turn can produce a claim containing that context. However when we sign in the second application using the same Auth0 session (sso between clients), we want to automatically use the context selected when the first application authenticated. Using user_metadata for this would not be ideal, as the selected context would both bleed between devices and be persisted between logins.
Question:
Is there a “session metadata”/“shared session state” object where we can tag this selected context?
Alternatively:
Is there a “Auth0 session id” exposed somewhere we can use to store this selected context ourselves? Looked at context.sessionID, but that returns a new id with every client authentication (even though they share Auth0 session). The closest I could get to a viable way of identifying the session was the timestamps of the methods in context.authentication, but seeing as that can contain multiple methods, it feels like using that could get messy pretty quick.
Mostly thinking out loud here, but the target of the redirect rule will have to be an HTTP(S) endpoint so that target can also manage its own session (through cookies) to track the fact that this is an existing context.
This would imply that the redirect would still need to be triggered, but it would respond immediately if there’s already a context for the user which triggered it. This would make the context claim bound to the browser session by default and additionally you could bound it to a user identifier.
The flow would be something like this assuming we start with a fresh browser session:
user access application and triggers a login.
user completes authentication in Auth0.
user gets redirected by rule.
target of redirect rule has no existing session so generates new context and binds it to the browser session through a cookie an optionally associates it the user identifier that you can send when triggering redirect.
user accesses second application and triggers a login.
due to SSO, credentials are no longer requested but redirect rule is triggered.
target of redirect rule checks that there is an existing context for this user and returns immediately with the same context.
Thanks for the answer, @jmangelo. Yes, something along those lines would probably work. The limitations/challenges with that is obviously that the selected context is not really bound the Auth0-session in any way. That means that forcing a new context selection upon expired or logged out Auth0-session is a bit tricky, but I have some ideas on how to get it working.
I’d still like to put in a couple of feature requests though.
A place to store custom session data. Could be handy in quite a lot of scenarios I think.
Exposing some kind of Auth0-sessionId on the context object passed to the rules.
I think having a more stable session identifier available in rules is something already tracked or at least that I have seen discussed. However, I would suggest that you leave both suggestion at Auth0: Secure access for everyone. But not just anyone.. The submission of feedback through that channel is reviewed directly by the product team so it’s the best way to perform suggestion or make feature requests.