I am wondering if a Multi-Tenant endpoint exists for Okta, where I could set up an Application to point at it, then an Okta User from another Tenant would be able to sign in and be redirected back to my app with their credentials (I’m assuming they would have to consent, too). I have been combing through the documentation, and while I have found a few diagrams here I haven’t had any luck with finding implementation details, I believe what I am looking for is Approach Three in the diagram.
In Microsoft Azure AD, this Multi-Tenant endpoint and concept exists using their /common endpoint and is detailed here. Does something similar exist for Okta?
Hi @pyoung-sp, as @erik mentioned setting up external IdPs sounds like the closest thing to what you’d want to do. You can enable users to sign in with Microsoft, Google, Facebook, etc. When they sign in, that creates a user account in your Okta tenant. Your application would simply point to your Okta tenant - Okta takes care of the integration with all the others.
Then your app redirects to Okta, the sign-in page would then have buttons for the different IdPs you’ve configured (or you can setup IdP routing rules if you know certain usernames / geographies will use certain IdPs.).
Thank you for the replies @erik and @abole. That doesn’t quite sound like what I am looking for. If you think about Google, when you sign in with your email, it all goes through one common endpoint, then routes you accordingly. I am looking to do the same with one Okta endpoint , one OIDC application , which then routes them accordingly to their Authorization Server, signs them in, and returns back to my Application. It seems that Okta’s way of doing this is to have my application handle the routing of the customer to the correct endpoint first, unless I am wrong.
That is possible in Okta. You would have a single OIDC application that the user /authorizes into.
You could have Okta present the Okta host login screen at this point which could include social login buttons which would then route the user to the IdP if clicked, signin, route back to Okta, then back to your app.
You could have Okta present the Okta host login screen an have the user enter their username where discovery rules run to decide if a user should be routed to a social login, signin, route back to Okta, then back to your app.
You could supply the id of a registered IdP in Okta in the /authorize call which would immediately route the user to the social login, signin, route back to Okta, then back to your app.
The only real thing to look out for is if you are using the Okta self hosted widget with IdP discovery. This will require some extra work since this is not supported out of the box.
Yep, what @erik said. Use discovery rules (aka IdP routing rules) if based on the request context, the user’s attributes or groups you can differentiate which IdP they need to login with. If you can’t work it out automatically, then it needs to be user selectable (buttons).
If you think about it, the IdP needs a way to work out which other IdPs to route the user. Even in microsoft land you need to select whether its a ‘personal account’ or ‘work or school account’ which provides some limited routing within microsoft’s ecosystem.
@erik@abole I guess I should be a bit more specific here. I am using Azure AD B2C for my User Store, and want to add Okta as an IDP to it. What I would like to accomplish is only having one OIDC application to perform the sign in, and redirect back to B2C but have that application function for multiple Okta Organizations. However it seems that the /authorize endpoint is linked to a specific Okta Tenant that I would have to know ahead of time, is that right @erik?
You could setup something like Your App > Azure B2C > Okta Org 1 and Okta Org 1 could have the other orgs setup as IDps to point to any other Okta orgs (Okta Org 2, Okta Org 3, Okta Org n). This would mean only a single endpoint to setup in Azure B2C.
Note: When Okta routes you to another IdP to login it auto creates a user account. This means that users in all your other Okta orgs would be duplicated (without passwords) into Okta Org 1.