Best way to handle cross-domain authentication using SSO

Hello Auth0 community,

I would like to know what would be the best scenario for my use case.

I have a production tenant registered with a custom domain (auth.myapp.com).

I have a Saas at platform.myapp.com that uses auth.myapp.com to authenticate users.

For a client, I would like to whitelabel my Saas and provide him with a version of my platform available at the domain of their choice (let’s say platform.clientdomain.com).

What would be the best architectural scenario for this use case ? Should I create a tenant available at the same domain than my client domain (auth.clientdomain.com) or could I use my current domain name (auth.myapp.com) to authenticate their users.
Am I going to encounter issues if I do the latter ?

Hi @jonlg

I assume that platform.clientdomain.com will have a different set of users than platform.myapp.com. Correct?

In this case, have two tenants: auth.myapp.com and auth.clientdomain.com, each tenant should have the same config (using your CI/CD deploy stack) but will have their own users.

You can share your domain, but this will mean that the client app will authenticate using auth.myapp.com which is not a great user experience.

John

Hey @john.gateley,

Thanks for your prompt response.

Indeed, the users originate from their system so they will definitely be different from the ones in platform.myapp.com.

One thing that I want to stress out here is that users are not meant to login (filling the login form) on auth.myapp.com but instead they will login on their own authentication system and then, later, being recognized on platform.clientdomain.com only using an SSO flow.

Could this extra piece of information make the one tenant to rule them all scenario more relevant ?

I’m also afraid of having all my client authentication providers spread over multiple and multiple tenants. I know CI/CD helps here but the overhead of setting everything up and maintain it does not worth the (somehow subjective) poor user experience. Moreover knowing that users are not meant to login directly on auth.myapp.com.

Regards,
Jon