Hello,
I am currently working on re-architecting a monolithic application into a set of microservices. Doing so also involves moving each new microservice to a second, new, domain. Throughout this migration I need to support existing SSO integrations that we have on the old domain while also leveraging Auth0’s custom db connection to lazily migrate existing users to the new platform. The new application uses your embedded login, which means that I need a custom domain in order to prevent any issues surrounding cors/third party cookies. From what I have read, each tenant can only have a maximum of 1 custom domain and each enterprise account can only have 1 production tenant. In my case it appears as though I need two custom domains. I am hoping to get any insight you might have into how I might be able to manage this situation? One thing I have thought of is that I might be able to disable the custom domain on the old platform and use a custom domain for the new platform instead. The reason why I think this might work is because the old application doesn’t use embedded login. Of course this means that users of the old platform would suddenly be logging in via different domain, which could be alarming. Again, any help/insight would be greatly appreciated.
Thanks!
1 Like
Hi @kenneth.buck
A late response, but in case it helps:
The new application uses your embedded login, which means that I need a custom domain in order to prevent any issues surrounding cors/third party cookies
I would say no new SPA application should use embedded login. It’s just too much trouble and error-prone, and it’s likely to get worse in the future as browsers get more strict. Embrace login at the identity provider’s domain (“Universal Login” in Auth0), you’ll end up with a cleaner application and a leaner SDK (auth0-spa-js).
From what I have read, each tenant can only have a maximum of 1 custom domain and each enterprise account can only have 1 production tenant. In my case it appears as though I need two custom domains. I am hoping to get any insight you might have into how I might be able to manage this situation?
That is correct, only one custom domain per tenant.
One thing I have thought of is that I might be able to disable the custom domain on the old platform and use a custom domain for the new platform instead. The reason why I think this might work is because the old application doesn’t use embedded login. Of course this means that users of the old platform would suddenly be logging in via different domain, which could be alarming.
The only issue with changing domains is that any session that a user might have had in the old domain will go stale and users will have to log in again.
In any case, the most important takeaway here would be to skip embedded login if possible.