Cross-Origin Authentication

An explanation of cross-origin authentication in Auth0 and its compatibility with browsers

Auth0 uses the cross-origin authentication flow when an embedded login form (the Lock widget or a custom login form) collects credentials in your application and submits them to an Auth0 domain. On Auth0, this flow has built-in protections, including third-party cookies for browser-side checks, for better authentication security across origins.

Using third-party cookies allows Lock and Auth0’s backend to perform the necessary checks to prevent phishing and other cross-origin attacks when creating a single sign-on (SSO) experience with the Lock widget or a custom login form. It also produces a secure login experience even if SSO is not a goal.

Cross-origin authentication applies only when authenticating against a directory using a username and password from a web application, and it can be enabled alongside Universal Login in the same app. For example, your application can use Universal Login for primary sign-in and rely on cross-origin authentication only for an embedded re-authentication or step-up flow. Social IdPs and enterprise federation use a different mechanism, redirecting via standard protocols like OpenID Connect and SAML. Native applications using embedded login use the standard OAuth 2.0 Token endpoint directly and do not need cross-origin authentication.

Browser considerations

Modern browsers (including Firefox, Safari with ITP, and Chromium-based browsers) restrict or block third-party cookies by default for privacy reasons. Web applications relying on third-party cookies for cross-origin authentication may fail in those browsers.

To make embedded login work reliably across browsers for production embedded web applications, use the same top-level domain for your application and Auth0 tenant. For example, host your app at https://example.com and your Auth0 custom domain at https://login.example.com.

With this configuration, the cookies are no longer third party and browsers do not block them. As a security best practice, we recommend using a custom domain or multiple custom domains with the same top-level domain.

For testing or in controlled environments with clear browser coverage requirements, you can create and link a cross-origin verification page that allows cross-origin authentication to work in those specific browsers when third-party cookies are still permitted.

Learn more

• Configure Cross-Origin Resource Sharing
• Hosted Login vs. Embedded Login
• Auth0 Universal Login