Embedded Login with Cross Origin Authentication

Hi everyone,

We’re building a proof-of-concept for a client (enterprise healthcare) to evaluate different Auth0 authentication approaches side-by-side. One of the POCs requires a fully custom embedded login experience — the user never sees any Auth0 UI, all authentication screens (login, signup, MFA enrollment/challenge etc) are built as custom React components with the client’s branding. Auth0 operates entirely in the background.

The feature set we need to support in this embedded UI:

  • Email/password login & signup
  • Social logins (Google, Microsoft, Facebook, GitHub, LinkedIn)
  • MFA
  • Recovery codes
  • Profile management

We have a custom domain configured (e.g., id.ourdomain.com).

The problem:

For email/password login in our own UI (no redirect), the only viable path seems to be Cross-Origin Authentication, which uses Password Grant under the hood. We explicitly don’t want to use ROPG/Password Grant for this or universal login.

Our questions:

  1. Is there any supported Auth0 mechanism to collect username/password credentials in our own custom UI and authenticate against an Auth0 database connection WITHOUT using password grant and WITHOUT redirecting to Auth0’s hosted login page?

  2. If not, what’s the recommended approach for an embedded login POC where the requirement is zero Auth0 UI visibility? Is Cross-Origin Auth still considered acceptable for this specific use case given we have a custom domain configured?

  3. Are there any upcoming Auth0 features or APIs that address this gap — something like a first-party authentication API that allows credential collection in your own UI with modern security flows?

  4. Does anyone have GitHub repos or reference implementations for a fully embedded login with Auth0 (custom UI, no Auth0 pages visible)? Specifically looking for examples that handle the full flow — not just basic login, but MFA enrollment/challenge, social logins, and profile management all within custom components. Most examples I’ve found either use Universal Login or only cover the basic email/password scenario.

  5. For those using Cross-Origin Authentication — we’re currently using webAuth.login() from the auth0-js SDK to send credentials directly to Auth0 without redirect:

webAuth.login({
  realm: 'Username-Password-Authentication',
  username: email,
  password: password,
  scope: 'openid profile email',
  audience: 'https://our-api'
});

Is webAuth.login() still the recommended method for this use case, or should we be using a different method/SDK? I’ve seen references to webAuth.client.login(), webAuth.crossOriginAuthentication.login(), and direct calls to /oauth/token — unclear which is the correct approach in 2025/2026 and whether Auth0 still actively supports this path.

Any pointers would be really helpful. Thanks!

Hi @monishchaganti2001

Welcome to the Auth0 Community!

The short answer is that for your specific, strict requirement of a fully embedded login experience with zero Auth0 UI , the Cross-Origin Authentication flow (which uses the Resource Owner Password Grant or ROPG) is indeed the only available mechanism .

However, this path comes with significant trade-offs in security, functionality, and long-term maintenance. Auth0’s strong and consistent recommendation is to use the Universal Login . While you want to avoid it for this POC, it’s critical to understand why it’s the recommended path and what you lose by embedding.

Is there any supported Auth0 mechanism to collect username/password credentials in our own custom UI and authenticate against an Auth0 database connection WITHOUT using password grant and WITHOUT redirecting to Auth0’s hosted login page?

No. There is no supported Auth0 mechanism to collect username and password in your own UI and authenticate the user without using the ROPG flow (/oauth/token with grant_type: 'password' ) or a derivative of it (like Cross-Origin Auth).

Any flow that avoids a redirect to Auth0’s secure domain fundamentally requires your application to handle the user’s raw password, which is precisely what modern OIDC/OAuth2 flows are designed to prevent.

If not, what’s the recommended approach for an embedded login POC where the requirement is zero Auth0 UI visibility? Is Cross-Origin Auth still considered acceptable for this specific use case given we have a custom domain configured?

  • Is it acceptable? “Acceptable” is a strong word. It is a supported legacy flow, but it is not recommended . Auth0 maintains it for existing applications that have this requirement, but strongly advises against it for new applications due to the inherent security trade-offs.
  • While your custom domain (id.ourdomain.com ) is critical for mitigating third-party cookie issues with Universal Login, it does not fundamentally change the security posture of the embedded flow. Your React application, running on app.ourdomain.com , is still a separate origin from id.ourdomain.com . More importantly, your application code is still directly handling the user’s password, making it a higher-value target for XSS attacks.

Are there any upcoming Auth0 features or APIs that address this gap — something like a first-party authentication API that allows credential collection in your own UI with modern security flows?

Auth0’s product direction is moving further away from embedded credential handling, not towards it. So, no, there is no plan to introduce a “first-party authentication API” that would allow you to handle credentials directly in your app. The gap is intentional, as it represents a security boundary.

Is webAuth.login() still the recommended method for this use case, or should we be using a different method/SDK? I’ve seen references to webAuth.client.login() , webAuth.crossOriginAuthentication.login() , and direct calls to /oauth/token — unclear which is the correct approach in 2025/2026 and whether Auth0 still actively supports this path.

If you are committed to the embedded Cross-Origin flow, you will be using either auth0-js or the Auth0 Lock SDK. However, the specific method matters.

  • webAuth.login() - A method designed for the ROPG flow. It takes the username and password and sends them directly to Auth0.
  • webAuth.crossOriginAuthentication.login() - A related method often used for silent authentication (checking for a session) in an iframe context, but it can also be used for ROPG.
  • Recommendation - For clarity, directly using webAuth.login() with the realm (connection name) specified is the most explicit way to perform this flow. Auth0 still supports this path for legacy reasons, but it is not the strategically recommended path for new projects.

Hope the information above is helpful regarding the matter, if you have any other questions, let me know!

Kind Regards,
Nik

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.