For most situations, Auth0 recommends that authentication transactions be handled via universal login. Doing so offers the easiest and most secure way to authenticate users. However, it is understood that some situations may require that authentication forms be directly embedded in an application. Cross-origin authentication provides a way to do this securely.
What is Cross-Origin Authentication?
When authentication requests are made from your application (via the Lock widget or a custom login form) to Auth0, the user's credentials are sent to a domain which differs from the one that serves your application. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities, including the possibility of a phishing attack.
Auth0 provides a cross-origin authentication flow which makes use of third-party cookies. The use of third-party cookies allows Lock and Auth0's backend to perform the necessary checks to allow for secure authentication transactions across different origins. This helps to prevent phishing when creating a single sign-on experience with the Lock widget or a custom login form in your application and it also helps to create a secure login experience even if single sign-on is not the goal.
Security in deprecated library versions
Cross-origin authentication performed using deprecated versions of the Lock (< v11) and Auth0.js (< v9) libraries is unsafe, and the deprecated versions will be removed from service on July 16, 2018. For any applications which have yet to update and are still using embedded login from those deprecated libraries, a mitigation to the danger has been applied. All requests to the deprecated endpoints from those applications will be fingerprinted, to allow the Auth0 server to compare the request with previous ones and further mitigate risks. This measure does not prevent attacks, nor does it remove the need to migrate applications.
Limitations of Cross-Origin Authentication
Because cross-origin authentication is achieved using third-party cookies, disabling third-party cookies will make cross-origin authentication fail.
There are two approaches you can follow to remediate the issue:
- Enable Custom Domains and host your web application in a domain that has the same top level domain as the Auth0 custom domain. This way the cookies are no longer third-party and are not blocked by browsers.
- Provide a Cross-Origin verification page that will make cross-origin authentication work in some browsers even with third-party cookies disabled (see the browser testing matrix below).
These issues are another reason why the more practical solution is to use universal login.
Configure Your Application for Cross-Origin Authentication
Configuring your application for cross-origin authentication is a process that requires a few steps:
- Ensure that the Allowed Web Origins field is set to the domain making the request. You can find this field in the Application Settings. Please note that the URLs specified for Allowed Web Origins cannot contain wildcards or relative paths after the domain.
- Ensure that your application is using Lock 11 or higher, or Auth0.js version 9 or higher.
- If you don't enable Custom Domains, you will need to author a page which uses auth0.js to act as a fallback for the cross-origin transaction. More information on setting up this page is provided below.
Create a Cross-Origin Verification Page
There are some cases when third party cookies will not be available. Certain browser versions do not support third party cookies and, if they do, there will be times that they will be disabled in a user's settings. You can use auth0.js in your application on a dedicated page to properly handle cases when third-party cookies are disabled. This page must be served over SSL.
Provide a page in your application which instantiates
WebAuth from auth0.js. Call
crossOriginVerification immediately. The name of the page is at your discretion.
When third party cookies are not available, auth0.js will render an
iframe which will be used to call a different cross-origin verification flow.
Add the URL of this callback page to the Cross-Origin Verification Fallback field in your Application's settings in the Dashboard, under the Advanced > OAuth panel.
Error Codes and Descriptions
When Auth0.js v9 (and Lock v11) is used for embedded login, it employs the /co/authenticate endpoint, which has the following errors.
|400||invalid_request||Invalid request body. All and only of client_id, credential_type, username, otp, realm are required.|
|401||unauthorized_client||Cross origin login not allowed.|
|400||unsupported_credential_type||Unknown credential type parameter.|
|400||invalid_request||Unknown realm non-existent-connection.|
|403||access_denied||Invalid user credentials.|
|403||access_denied||Wrong email or password.|
|401||password_leaked||This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application).|
|429||too_many_attempts||Your account has been blocked after multiple consecutive login attempts. We’ve sent you an email with instructions on how to unblock it.|
|429||too_many_attempts||We have detected suspicious login behavior and further attempts will be blocked. Please contact the administrator.|
In addition, you can also get a generic 403 error without an
error_description property. The response body would just include something similar to the following:
Origin https://test.app is not allowed.
Browser Testing Matrix
This table lists which browsers can use cross-origin authentication when third-party cookies are disabled.
|OS||Browser||Cross-Origin Authentication Supported
with Third-Party Cookies Disabled
|Android Galaxy S7||Chrome||No|
|Android Galaxy S7||Firefox||Yes|