Hi,
I’m looking for the best way to implement a ‘switch account’ flow for my app. I use the hosted page with custom DB connection. On login I add a claim that represents the account the user should have access to (i.e. https://api.myapp.com/account_id: 12345).
It is possible for users to have multiple accounts and be able to seamlessly switch between them (think tenants on Auth0).
I’ve implemented a rule that will, as part of the auth flow redirect to the app to choose what tenant to log in to, passing back the specific claims to add to the access token. The problem is the switching of accounts once logged in.
I thought that I can send through acr_values (I’ve had a previous implementation not in Auth0 doing it this way) and use that to explicitly pick the account, instead of having the user manually choose. The problem is I either send prompt=none and that does not work, or I do not send that at all and the user is shown the login page again even though they are logged in.
Any thoughts on how I could achieve this? How can I, in essence, update the accessToken with new claims for a logged in user?
Thanks, Adam
Hey,
One of the remarks noted in the documentation of the /userinfo endpoint states the following:
To access the most up-to-date values for the email or custom claims, you must get new tokens. You can log in using silent authentication (where the prompt parameter for your call to the authorize endpoint equals none)
You mention that you’re already sending prompt=none, but that doesn’t work. Are you sending this request by redirecting the user to Auht0 or in some other way?
What technologies and libraries are you using in your app, and to integrate Auth0 into it?
Hey,
I’ve thought about this some more and realised I just needed to do things a little differently.
The issue was not that prompt=none did not work, but that the flow I had originally created for swapping tenants involved redirecting the user to a “choose page”, which I would have pre-populated with a selected tenant. That does not work with prompt=none as it returns an error to force interaction.
What I do now is to generate a JWT token that is passed as part of the acr_values (i.e. tenant:JWT_token) query string parameter. This is then decoded, verified and the additional claims / changed claims handled in the same way as the JWT I get from the choose account redirect flow.
Thanks for your reply
Hey there!
Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.
Wanted to reach out to know if you still require further assistance?