As a SaaS business, different companies login to our app.
We already have a login page/ signup offering local login (email/password) and Connect with Microsoft button implementing OIDC (see attached schema).
We would like to add Okta as some of our customers actually request it.
We do not understand how to add a «Connect with Okta» button on our login page that would lead the user to the proper Okta login page. While building the authorization URL, as an ISV we should address a generic Okta provider URL which will do the IdP discovery for the customer right ?
Do you provide documentation about this?
Here are the steps as I understand them so far, assuming we have our App in the OIN:
1 - The customer adds the App for his organization in Okta
2 - The customer grants access to the App for desired set of Users/Group
3 - An end user arrives on our webapp, landing on the login page
4 - Clicks on ‘Connect with Okta’
5 - The user is presented a login page from Okta (auth + consent process)
6 - The Authenticated User is redirected to our platform (after account creation/retrieval on our backend and session opening)
If you are building an OIN app, that means that Okta admins will be adding your application to their Okta tenant. This means that all OAuth calls should be made to their org, in order to request tokens for their users. You will want to provide some way for these Okta Admins to provide their environment variables with you to set-up the integration on your side (Okta Domain, Client ID, and Client Secret)
Because OIN applications cannot use custom Authorization servers, as noted in this guide, the authorize URL your application should be constructing should look like this: https://customersOktaDomain/oauth2/v1/authorize?client_id={{clientIDfromOINAppInCustomersOrg}}
Many thanks for your answer.
Though, I don’t understand, considering that the login page is public and the user not identified, how does the application can build the authorize URL toward the proper tenant (customersOktaDomain) ?
For the same flow, with OIDC SSO integration with Microsoft, the end user is carried to the global authorize URL: https://login.microsoftonline.com/common/oauth2/authorize?client_id=<app_id>&nonce=xxx&state=yyy&redirect_uri=<redirect_uri>&response_type=code%20id_token&scope=openid%20profile%20email
It seems that Okta hasn’t got such global URL as far as I have seen. What flow do you suggest to find out the proper tenant for the authorize request ?
That’s correct, there is no central/common URL used for authorization across all Okta tenants, as you would expect to find for Social Auth. You’ll find this to be the case in many enterprise IdPs; for example, Azure AD has tenant IDs as part of their OAuth endpoint URLs.
Most likely the simplest solution would be to try prompting the user for their subdomain/Okta domain (in case they have a vanity URL configured) and using that to construct the authorize request. Of course, since the Client Ids are also specific to each Org (aka, each Org would need to have a client configured/created/available for this purpose), you would likely need to store a look up table of sorts to correlate Okta domains with their associated Client Ids
OIN is baffling. It sounds great for your clients and very complex to implement for application providers. How can we securely gather client id and secret from the Okta tenant?
An architectural diagram would be very helpful, I’ve read through the docs about OIN and I’m still confused about the work flow. Is it truly automated? Why is client documentation required?
We also have a client that would like to use their SSO via Okta, but it’s not clear where to start. We already have a OIDC Okta application that is not on OIN.
As the client credentials only exist within your customer’s Okta tenant, you will need to find a secure way for them to transmit that information to you which would be a step to include in the documentation for your OIN submission to help admins get all set up.
You don’t have to submit your app to the OIN, your client could instead create a custom OIDC app in their org and configure it manually to point to your application. This will still require them to provide the client id/secret to you of course.
I would prefer if Okta found a secure way to transfer that information. Ideally installing an OIN app would ask the org for permission to provision users (they can set their own rules here) and on my side, as the provider of the app I would accept that provisioning.
I use Okta so I don’t have to handle sensitive Auth information like client secrets, passwords, password resets, mfa, etc.
