SSO as the Service Provider

I just submitted my app to the OIN. I noticed that most applications only require you to enter you subdomain to integrate with them, for example the Zoom app. We are using Okta, are the service provider, and would like to have a similar setup. However, Okta requires me to create an IdP for every customer that integrates with us, thus for every customer there will be a unique audience uri that is not predictable.

How do I make setting SSO for my customers simpler using Okta? i.e. I give them a unique id (tenant, subdomain, or whatever it may be), and that is all they need to integrate with us.

I am looking for answer on this as well. We are an SP hoping to integrate with Okta (although we do not use Okta ourselves.)

What I’ve gathered from my own research (I could be wrong) is that a multi-tenant integration scenario must be done using SAML, registering each customer’s Okta tenant as an Idp. This is no trivial task and requires familiarity with SAML. I am wondering if there is a way to use the Okta SSO Widget (which I believe is driven by OIDC/OAuth 2.0) as an SP with multiple customers on separate Okta domains. Any examples I see for SSO require that a specific domain be specified.

Any insight would be appreciated.

Hi @quantumew @samnutkins

You can create a “Single Sign-on” page under the Settings section for your customers. In this page, the customers can specify the SAML settings and have them saved in the database.

When a single sign-on connection event occurs, Okta will send the request to the customer’s tenant on the ACS endpoint, which can be something like https://$tenant.application.com/callback, https://application.com/$tenant/callback or any variation of the URL in which the tenant is specified. When the request reaches your application, you can parse the URL to retrieve the tenant ID / subdomain, query it in the database to retrieve the SAML configuration and then parse the SAML assertion based on the configuration.

1 Like

Interesting, going to try this, thanks for the info!

Hey @dragos, just to be clear, this would mean not using Okta’s SAML IdP and instead writing an application that can handle SAML requests, am I understanding that correctly?

The downside of that is all of our applications authenticate with Okta using OIDC, if we use Okta’s IdP our apps don’t have to know about SAML, they make the same authorization request regardless of how the user obtained their session.