Centralized Universal Login vs. Embedded Login
When you design the authentication experience for your application, you have to choose whether the login flow will use universal or embedded login.
With Universal Login, when the users try to log in they are redirected to a central domain, through which authentication is performed, and then they are redirected back to the app. An example is G Suite. No matter which service you are trying to access (Gmail, Google calendar, Google docs, etc) if you are not logged in you are redirected to
https://accounts.google.comand once you successfully log in you are redirected back to the calling app.
On the other hand, an embedded login flow does not redirect the user somewhere central. The login widget is served from the same page without redirecting the user to another domain. The credentials are then sent to the authentication provider for authentication. In a web app, this is a cross-origin request.
Pros and cons
| Feature | Centralized | Embedded |
|---|---|---|
| Single Sign-On | If you are working with mobile apps, you cannot have SSO unless you use Universal Login. With web apps you can, although the most secure way is to use a central service so the cookies are from the same origin. | With embedded login, you'd have to collect the user credentials in an application served from one origin and then send them to another origin, which can present certain security vulnerabilities, including the possibility of a phishing attack. |
| Consistency and Maintenance | Your Authorization Server (the domain that logs the users in) owns all the login pages which makes the management easier and the pages more consistent and secure. You could also use a single login page among your apps, a process that creates an impression that users are logging into a centralized system, rather than an individual app. | If you have more than one app, you must implement more than one login page. You will also have to maintain and manage these pages. Besides the extra effort it can also introduce inconsistencies which results in bad UX. Furthermore, with embedded login you would have to manage the dangers of cross-origin attack vectors. |
| Feature Management | You can turn on and off features such as MFA, across all your apps, using the Dashboard. | Must be done for each application individually. |
| User Experience | Redirected to another subdomain to log in. | Not redirected to another subdomain to login. |
| Mobile Apps and Security | According to the Best Current Practice for OAuth 2.0 for Native Apps Request For Comments, only external user agents (such as the browser) should be used by native applications for authentication flows. Using the browser to make native app authorization requests results in better security and it gives users the confidence that they are entering credentials in the right domain. It also enables use of the user's current authentication state, making Single Sign-on (SSO) possible. | Embedded user agents are deemed unsafe for third parties and should not be implemented. With native login a malicious app could try and phish users for username/password or tokens. Also, if your mobile apps use native login, then your users have to enter their credentials for each of your apps, hence SSO is not possible. |
Security risks
Universal Login is more secure than embedded login. Authentication takes place over the same domain, eliminating cross-origin requests. Cross-origin authentication is inherently more dangerous. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities. Phishing attacks are more likely, as are bucket brigade attacks. Universal Login does not send information between origins, thereby negating cross-origin concerns. To learn more, read Prevent Common Cybersecurity Attacks.
Embedded user agents are unsafe for third parties, including the authorization server itself. If an embedded login is used, the app has access to both the authorization grant and the user's authentication credentials. As a consequence, this data is left vulnerable to recording or malicious use. Even if the app is trusted, allowing it to access the authorization grant as well as the user's full credentials is unnecessary. This violates the principle of least privilege and increases the potential for attack.
Google no longer supports an embedded approach when implementing OAuth. Furthermore, according to the Internet Engineering Task Force (IETF), authorization requests from native apps should only be made through external user agents, primarily the user's browser. Using the browser to make native app authorization requests results in better security. When embedded agents are used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use.
Another helpful resource is Modernizing OAuth interactions in Native Apps for Better Usability and Security at https://developers.googleblog.com.
Universal Login with Auth0
For most situations, we recommend using a Universal Login strategy, where Auth0 will show a login page if authentication is required. You can customize your login page using the Dashboard.
You can use Auth0's Custom Domains to persist the same domain across the login page and the app. The redirect to the login page will be transparent to your users because the domain will not change. To learn more, read Custom Domains.
Whenever your app triggers an authentication request, the user will be redirected to the login page in order to authenticate. This will create a cookie. In future authentication requests, Auth0 will check for this cookie, and if it is present the user will not be redirected to the login page. They will see the page only when they need to actually log in. This is the easiest way to implement SSO.
Note that if the incoming authentication request uses an external identity provider (for example, Facebook), the login page will not be displayed. Instead, Auth0 will direct the user to the identity provider's login page.
You can deploy your custom login page from an external repository, like GitHub, Bitbucket, GitLab, or Microsoft Azure.
Our recommendation is to use Universal Login when you use Auth0. The first and foremost reason is security. Using Auth0 Universal Login instead of embedding login in your application provides seamless CSRF protection. This helps prevent third-party impersonation or the hijacking of sessions.
Embedded login with Auth0
Embedded logins in web apps with Auth0 use cross-origin authentication. (To learn more, read Cross-Origin Authentication). This uses third-party cookies to allow for secure authentication transactions across different origins. This does not apply to native applications since they use the standard OAuth 2.0 /token endpoint. To learn more about third-party cookies, read Tracking and privacy: Third-party cookies at https://developer.mozilla.org.
Auth0 does not recommend using cross-origin authentication, however, if you do, only when authenticating against a directory using a username and password. Social IdPs and enterprise federation use a different mechanism, redirecting via standard protocols like OpenID Connect (OIDC) and SAML. Additionally, cross-origin authentication is only applicable to embedded login on the web (using Lock or auth0.js). Native applications using embedded login make use of the standard OAuth 2.0 Token endpoint.
In addition, if you have not enabled custom domains, the end-user must have a browser that supports third-party cookies. Otherwise, in some browsers, cross-origin authentication will fail. This limitation applies to both traditional username/password database connections as well as passwordless database connections.