OIDC authorize URL for ISV's OIN Apps

Questions
#1

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)

Authentication Sequence
Authentication Sequence848×1406 97 KB

Where we are stuck so far is at point 4 to 5, where the /authorize URL is built, what tenant shall be requested? what is the complete URL ?

#2

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}}

#3

Hello Andreas,

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 ?

#4

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