Migrate from Embedded Login to Universal Login
When you integrate Auth0 into your applications, you have to decide whether you will use embedded or Universal Login.
With embedded login the login dialog is hosted in your application. You can use Lock or create your own UI and use auth0.js.
With Universal Login, you redirect to an Auth0-hosted login page where the authentication flow is performed.
Universal Login has several advantages over embedded login. For a detailed analysis refer to Centralized vs Embedded Login.
You can also find how to implement Universal Login in multiple technology stacks using Quickstarts.
Embedded Login Scenarios with Single Sign-On
Migration from legacy versions of Lock and Auth0.js is required. For Single Sign-on (SSO) scenarios, it will imply moving to Universal Login in most cases.
Single-Page Apps
Single-Page Applications (SPAs) with embedded login can only achieve SSO if they are on the same top-level domain. If SPAs with embedded login which are on different domains require SSO, the websites will need to migrate to Universal Login.
SSO works by having Auth0 set a cookie that identifies the session in the Auth0 server for a specific domain.
In order to make embedded login work properly, you need to set up a custom domain that matches your website's top level domain, so as to avoid cross-origin authentication issues.
If two applications using embedded login are sitting on different top-level domains, they would need to point to two different custom domains in order implement embedded login properly. If they are on different domains, those domains cannot share the same SSO cookie, so you can’t implement SSO across those sites.
Web Apps
Web Applications using embedded login that require SSO need to migrate to Universal Login.
The proper way of implementing embedded login for web applications is by creating a custom form that POSTs credentials to the web application. The web application then validates them with Auth0 using the /oauth/token endpoint.
This approach does not allow for the creation of an SSO session, as the Auth0 server cannot set a cookie in the end-user’s browser. It also prevents Auth0 from performing attack protection.