Configure Cross-Origin Resource Sharing
Auth0 strongly recommends that authentication transactions be handled via Universal Login. Doing so offers the easiest and most secure way to authenticate users. However, some situations may require that login be directly embedded in an application. When embedded login is required, an application must be set up for cross-origin resource sharing (CORS).
You can configure CORS for an application using the Auth0 Dashboard.
For security purposes, your app's origin URL must be listed as an approved URL. If you have not already added it to the Allowed Callback URLS for your application, you will need to add it to the list of Allowed Origins (CORS).
Ensure that Allowed Web Origins in your applications Settings tab is set to the domain making the request. The URLs can contain wildcards for subdomains and cannot contain relative paths after the domain URL. To learn more, read Placeholders for Subdomains.
If you don't enable Custom Domains, you will need to create a verification page that uses Auth0.js as the fallback for the cross-origin transaction.
Configure cross-origin authentication
Go to Dashboard > Applications > Applications and click the name of the application to view.
Under Application URIs, locate Allowed Origins (CORS), enter your app's origin URL.
Click Save Changes.
Create 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, they may be disabled in a user's settings. You can use Auth0.js in your application on a dedicated page to handle cases when third-party cookies are disabled. This page must be served over SSL.
crossOriginVerification as a fallback will only work if the browser is on the support matrix as Yes under Third-Party Cookies Disabled. For some browsers, such as Chrome, Opera, and Safari, when third-party cookies are disabled, cross-origin authentication will not work at all unless you enable Custom Domains.
Create a page in your application that instantiates
WebAuthfrom Auth0.js. Call
crossOriginVerificationimmediately. The name of the page is up to you.When third party cookies are not available, Auth0.js renders an iframe to call a different cross-origin verification flow.
to configure this snippet with your account
Was this helpful?/
Go to Dashboard > Applications > Applications and select your application and click Advanced Settings at the bottom of the page.
On the OAuth tab, add the URL of the callback page you created to the Cross-Origin Verification Fallback field. For production environments, verify that the Location URL for the page does not point to localhost. The page must be in the same domain where the embedded login form is hosted and must have an https scheme.
Click Save Changes.
See the cross-origin auth sample HTML in GitHub for more details.
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.
||Invalid request body. All and only of client_id, credential_type, username, otp, realm are required.|
||Cross origin login not allowed.|
||Unknown credential type parameter.|
||Unknown realm non-existent-connection.|
||Wrong email or password.|
||This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application).|
||Your account has been blocked after multiple consecutive login attempts. We’ve sent you an email with instructions on how to unblock it.|
||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 support
The following browsers can use cross-origin authentication when third-party cookies are disabled:
Microsoft Internet Explorer
Samesite cookie attributes
Previously in Auth0, the
samesite cookie attribute options were
lax. If you didn't set the attribute manually, Auth0 would use the default value of
Effective February 2020, Google Chrome v80 will change the way it handles cookies. To that end, Auth0 plans on implementing the following changes to how it handles cookies:
Cookies without the
samesiteattribute set will be set to
sameSite=nonemust be secured, otherwise they cannot be saved in the browser's cookie jar
The goal of these changes are to improve security and help mitigate CSRF attacks.