I work on a SaaS app (oncallscheduler.com). We have customers authenticating through OpenID Connect (OIDC) against Microsoft and Google directories. We now have a customer which would prefer to authenticate against Okta, and so we are working on that. We will want to have an “Okta login” type button on our web site, and end users who authenticate that way should be able to click on it, get redirected to the Okta logon page, and then redirected back to our web app when the authentication is done.
We want to request the minimal information the app needs about the user, so only use the scopes “openid” and “email”. We don’t use “profile” since that gives access to all kinds of stuff.
This all works like we expect, but we have run into a problem: Is there an id token claim to identify the Okta customer tenant the authenticated user comes from?
We’ve seen in youtube videos that there sometimes (perhaps in the past?) is an “identityprovider” claim with a tenant id. There’s also the “idp” claim, but that seems to be an id for Okta itself as an identity provider. There’s the “iss” claim which is a customer tenant identifier in Microsoft OIDC. But in Okta OID the “iss” claim seems to be the “Authority” URI which our app redirected to when asking Okta to authenticate a user (=a URI pointing to our Okta developer tenant).
Questions:
Is there a way to send users from all kinds of Okta tenants to one URL for them all to authenticate?
When you do that, and you get an id token back, is there any id in there for the Okta tenant the authenticated user belongs to?
As I was researching this, I realized there’s a lot about Okta, and how it differs from Microsoft and Google identity providers, which I had not understood, and which makes a big difference for how my SaaS can integrate with Okta. I’ll share that here for the benefit of others who have the same challenge.
First, the answer to my question above is “no”. There is no way to show one Okta login button which will work for all Okta customers to authenticate through. This is because (if I understand things correctly) Okta tenants don’t have a concept of exclusive domain ownership. That is: a user with the same email address (e.g. ceo@okta.com) can be present in a whole bunch of Okta tenants, with different passwords and other identity data. So there is no way for Okta to expose 1 login form where the user’s domain (or whole user identifier) could be used to route the login to the right Okta tenant.
This means a SaaS app can’t show an “Okta” login button next to Microsoft/Google/… login buttons.
I assume the Okta vision for how SaaS apps should work, is that users should find the SaaS apps through the Okta list of apps enabled for a tenant. When a user clicks on the app there, the authN context for the right tenant can be passed on to the app. I haven’t built that yet, but I think that’s what I’ll need to do.
In addition to this, for Okta customer users who go straight to our SaaS app web page, I’ll build a flow where they can enter their email address, so I can look up their tenant in our app’s data (where we do treat user identifier domains as being tenant-exclusive), and then send them for authentication to an Okta Authority URL that maps to their Okta tenant. Unlike customers which use Microsoft or Google authN against my SaaS, Okta customers will need to configure their Authority URL for my app somehow.
If I have misunderstood any of this, I’d love help to learn about that.
You’re correct in that Okta is an Enterprise Identity Provider and does require that a dedicated application instance be created within each Okta tenant in order for users to be able to SSO into a a given application.
Your approach of gathering the username and then doing a lookup behind the scenes to determine which Okta tenant (and associated application credentials and configurations) to use so you can trigger an authorization request makes sense to me. This would mean that you would need to provide a way that your customers can share their instance specific details (namely their Okta domain/issuer url and Client ID)
You may also be interested in getting your SSO integration added to the Okta Integration Network. You can find more info about this process in our guides here: Okta Integration Network | Okta Developer