SSO Across Multiple Custom Domains in Same Tenant

Questions
1

Hello Okta team,

I’ve been looking through the Okta documentation and learned that sessions aren’t shared across custom domains in the same Okta tenant. Given this, I’m exploring possibilities for achieving Single Sign-On (SSO) across multiple custom domains associated with our Okta tenant. Is there a recommended approach or workaround to enable SSO in this scenario?

2

SSO in any IdP, not just Okta, uses a session cookie (in Okta it’s the IDX cookie) to decide if you already have a session. That’s in the Okta organization (tenant), not your application. That is why SSO across different custom domains doesn’t work, the session cookie for one domain doesn’t get sent for another. There really isn’t any good way for this to work on the Okta side.

On the application side you could use shared session cookies for your own applications, and one application could see from that the user is already authenticated.

I have to ask why this scenario though? I expect you have a good reason, but If I was a workforce or customer user and I was accessing a different domain, it would be very disconcerting to me if SSO did kick in. It would make me think something is seriously wrong or there is a security breach.

1 Like
3

Hi @jmussman
Thanks a lot for the reply and detailed information.
We have a similar question that was raised earlier this month here.

In our setup the custom domains are under the same top level domain, but one is a subdomain, e.g:
identity[dot]company[dot]com and app1[dot]identity[dot]company[dot]com

Would it be possible to have SSO working in this case?

Regards,
Simon

4

Unfortunately the authorization server doesn’t distinguish sub-domains. For example, I have an Okta tenant at https://pid.pyrates.live and the cookie is written for ‘pid.pyrates.live’, not ‘pyrates.live’ (one of my demo sites). So Okta SSO will not cross sub-domains for authorization servers, even if you tried to configure that. This is true of every identity provider I have worked with: Okta, Auth0, etc.

You can make your own “SSO” work without revisiting the authorization server if:

  1. You set your own application session cookie at the parent domain level.
  2. All the applications in the sub-domains honor the cookie.
  3. Carry the local ID of the authenticated user in the cookie, so the applications in the sub-domain can use it as a key into shared databases.
5

You referenced the post Okta SSO between different Okta domains but same Okta tenant, so I’m looking at that and addressing it over there :slight_smile:

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.