Hello, totally new to SSO. Thank you for any help.
We have 50 clients, each with their application housed in their corresponding subdomain… clientA. domain. com , clientB. domain. com , clientC. domain. com , etc.
If most clients are in the Auth0 database of users, how can I redirect user james to clientA. domain. com (and no other domain), user linda to clientB. domain. com (and no other domain), etc.?
Does each subdomain need its own login page that “knows” what domain it came from, for purposes of redirect after user validation?
If a user logs in using a single, standard Auth0 login page, how can we determine what subdomain to send the user to after validation? I’ve read that metadata can house user data, but we’d like to not write metadata to a user’s account. Does the ability to write metadata require the Enterprise plan? Plus, it affects #2, below.
If some clients already use Okta (Auth0 seems easier for us to integrate so far), we don’t know who those users are. If their user logs in using Okta’s login screen, then Okta should validate them – we need to redirect that Okta-housed user through Auth0, and then figure out what subdomain to send the user to (and no other subdomain). Can you describe how we can make this process work?
I’m just posting again with this architecture question, above (and, I’ve tried reading Auth0’s architecture articles, but I’m still lost given our intended use). Thank you for any responses.
1.)You would want some mechanism to determine which redirect_uri to pass with the authorize request, this is the only way to change where the use goes (directly) after authentication, but further redirections could be put in place after that.
One way would be to have vanity URLs for each client, for example clientA would go to login.domain.com/clientA , (or it could be a querystring parameter). This vanity URL would then be able to redirect the user to the authorize endpoint with the correct redirect_uri for that customer and application.
You can further/alternatively control this using state or cookies/browser session on your applications side, as mentioned here: Redirect Users
You may also want to review this documentation here: Multi-Tenant Applications Best Practices - there are a couple ways shown there to handle multiple groups of users.
2.) You would need to do the same as mentioned in 1.) for the redirection part, and get the users to login to Okta by going to Auth0 first, i.e. don’t use IDP initiated flows. Enterprise connections support home realm discovery, which can send the user to the relevant Enterprise IDP based on their email domain. There is some more detail on this here: Select from Multiple Connection Options
You could also specify the connection parameter in your authorize URLs, to fast track the user to the relevant IDP - Authentication API Explorer
Either way, you would want your Okta users to use an SP initiated flow (i.e. Auth0 authorize url), and you could provide such a link in an Okta portal for example.