Skip to main content

Documentation Index

Fetch the complete documentation index at: https://auth-test.auth0-mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

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 (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 and enterprise federation use a different mechanism, redirecting via standard protocols like Connect and . Native applications using embedded login use the standard 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