I'm developing an identity and access management middleware for my company. All of the identity providers we support will funnel through this middleman, which all the backend applications can talk to. On our home page, we want to provide buttons that quickly allow our customers to log in using their own identity provider. With Azure AD, we had to use the "common" OAuth endpoint to allow Azure AD to negotiate which instance the user belongs to. Now that I'm trying to implement Okta, I see no mention anywhere of a "common" entry point for the SAML request. Instead, the entry point I'm using is tied to my developer instance of Okta, which is unaccesible to anyone but me. Is there such an entry point available? I can't find any mention of it on my application's configuration nor in the documentation and samples provided.
Actually, just the opposite. The flow looks something like this:
A user (unknown identity, unknown tenant) comes to our home page and clicks the button to sign in with Okta
The application triggers a SAML request and redirects the user to Okta
Okta determines the tenant the user belongs to (which is the Okta instance) and authenticates the user
Okta returns a SAML assertion to the application with the identity of the user and Okta instance
I'm having trouble with parts 2/3. Currently, I'm redirecting the user to my Okta instance directly for them to sign in. Instead, what I need is a "common" Okta entry point that can direct the user to the appropriate instance for authentication. We want our customers to be able to use their own Okta instance directly.
Hi Matthew I think I get it now. in #3 there are multiple Okta instances? In this case, you need "IdP discovery". One way to do this: 1. a user goes to your home page and you ask them which Okta instance is going to authenticate them. You could show a drop-down, or ask for an email address and look at the suffix 2. you then send the user to the correct IdP I don't think this something Okta can do directly, your code would have to decide.
Yes, Gabriel, that's exactly it. Are you sure this is something that Okta can't support directly? The SAML response includes a field for the instance ID, which would allow for this easily. As I mentioned before, we've already implemented Azure AD with our product, and although there's a bit more configuration required on our side (we have to enable the application as "multi-tenant"), we can use a common endpoint that handles instance negotiation for us (so that a user, if already logged in, for example, wouldn't have to additionally select their Azure instance--which we would have to do with Okta if we follow your steps).