What Is Embedded Authentication?

Most authentication flows ask the user to leave. Click "Sign in," watch the URL change to accounts.somebody-else.com, type a password into a page that looks nothing like the one before it, then get redirected back. The whole thing takes about four seconds and breaks a quiet trust contract: I was using your product, and now I'm not.

Embedded authentication is the alternative. The sign-in surface lives inside your application — same domain context, same branding, often the same page. The user types their email and password into your product. There's no redirect, no foreign favicon, no "you are leaving this site" moment.

That sounds like a UX detail. It isn't. Choosing embedded auth changes how you handle CORS, cookies, CSRF, token storage, and (most importantly) where the trust boundary sits in your system. This article is about what embedded auth actually is, when it's worth the cost, and the architectural choices it forces you to make.

The three places authentication can live

Before "embedded" means anything, it helps to name the alternatives. There are roughly three places a sign-in form can render:

1. Hosted (redirect-based) — Users are sent to a separate domain (auth.yourcompany.com or a third-party domain like login.auth0.com). The auth provider owns the page. You get back a token or a session cookie.
2. Embedded same-origin — The form is rendered by your application directly. Same domain, same React tree, your CSS.
3. Embedded cross-origin (iframe) — The form is rendered by a different domain inside an iframe in your page. Looks embedded, technically isn't.

Each option moves a different problem around. Hosted auth gives you the simplest implementation but the worst UX. Same-origin embedded auth gives you the best UX but pushes the auth UI into your own bundle and your own security review. Iframe embedded auth gives you the UX of embedded with the maintenance model of hosted — at the cost of a lot of browser plumbing (we've written about why iframe auth is hard).

The user's experience in cases 2 and 3 looks identical. The engineering effort and security posture do not.

What makes auth feel "embedded"

It's tempting to define embedded auth by "no redirects," but that misses the point. A user signing into Notion via Google still gets redirected to Google — and nobody complains, because Google is somebody else's product. The "stay inside the product" rule applies to the application's own credential flow.

A reasonable working definition:

Embedded authentication is an auth flow where the user enters their primary credentials (password, magic link, OTP) on a page they perceive as belonging to your product.

Three things define the perception:

• The URL bar doesn't change to an unrelated domain.
• The visual frame (header, nav, colors, typography) stays consistent.
• State (cart, draft, what they were doing before they signed in) is preserved.

The third one matters more than people give it credit for. The single largest cause of cart abandonment in e-commerce isn't price — it's "log in to continue." When that click drops the user's session state, they leave.

Why teams choose embedded auth

You don't pick embedded auth to be clever. You pick it because something about your business demands it.

B2C funnels. Sign-up conversion is a conversion-rate problem, and conversion problems are won by removing every reason to bail. Each redirect is a reason. Companies with a measurable sign-up funnel — e-commerce, consumer SaaS, fintech — usually end up embedded.

White-labelled products. If you're a platform that other companies put their brand on (Shopify-for-X, vertical SaaS), a hosted auth page with your logo is a contract violation. Embedded — even better, customizable embedded — is the only honest answer.

Reduced perceived dependency. Auth-as-a-service providers historically branded their hosted pages. End users would see "powered by Auth0" or notice the domain change. Some founders prefer that surface to look like the rest of the product. Embedded hides the seam.

In-context auth. Some flows need to re-authenticate the user mid-session — to confirm a sensitive action, switch organizations, or escalate privileges. Embedded auth lets you ask "confirm your password" in a modal without unmounting your application.

What embedded auth changes for engineering

Hosted auth pushes a lot of the security complexity to a different domain. That's not nothing — same-origin cookie attacks, XSS-driven token theft, and CSRF all behave differently when your auth form runs in your own application's JavaScript context.

Here is what you take on when you embed:

1. The auth form is in your XSS blast radius. Any successful XSS in your application can read what the user types. With hosted auth, an attacker who XSS-es your dashboard can steal session cookies but can't capture the password (the password is never entered into your app). With embedded auth, they can. This raises the bar on CSP, dependency hygiene, and template escaping.

2. CSRF moves to your problem. Hosted auth providers handle CSRF on their domain. When the form is on your domain, you implement double-submit cookies or origin checks for the login POST, plus every other state-changing route. This is well-trodden ground but it stops being free.

3. Cookie strategy gets harder if there are multiple apps. If app.example.com and marketing.example.com need to share a session, you need cookies scoped to .example.com. Embedded across multiple subdomains forces you to think about session boundaries early.

4. You own the rate limiting. Failed login attempts, brute force, credential stuffing — all your problem. Hosted providers ship this. If you embed, build it.

5. Account recovery flows multiply. "Forgot password," "verify email," "MFA fallback," "device approval" — each of these has the same hosted-vs-embedded choice. Most teams pick embedded for the happy path and then accidentally redirect to a hosted page for recovery, which feels jarring. Plan for all of them up front.

The "embed but don't own" pattern

There's a middle path that's become popular: render the auth UI inside your application via an iframe, but have the iframe served by an auth provider. The user sees an embedded experience; the password never touches your application's JavaScript.

This pattern moves the password entry out of your XSS blast radius while keeping the same-domain appearance. The price you pay is:

• Cross-origin coordination via postMessage, which has its own pitfalls (origin validation, message replay).
• Cookie handoff requires a same-domain callback endpoint that the iframe can navigate the parent to, since iframes can't write cookies for the parent.
• Third-party cookie deprecation (Safari ITP, Chrome's CHIPS) breaks naive implementations.

This is the model EmbedAuth uses, and it's the model a lot of "auth components" from SaaS providers use under the hood. It's a real architecture, not a hack — but the engineering is genuinely harder than people expect on first read.

A decision framework

If you're standing at the start of this choice, here's how we'd think about it:

Notice that "small team" leans hosted. That's not a slight — running embedded auth securely is a real engineering commitment. If you're three engineers and one of them is part-time, you don't want a credential intake form in your blast radius.

The thing nobody tells you

Embedded authentication is rarely a one-time decision. The first form goes up easily. Then someone wants social login (now you have OAuth callbacks landing on some domain). Then someone wants MFA (now you need a TOTP screen, a recovery flow, an enrollment flow). Then enterprise asks for SSO (now you have SAML, and SAML is its own essay).

Each of these touches the embedded/hosted question. The mistake is deciding "we're an embedded auth product" and then designing each new flow without revisiting. Some flows — SSO callback, SAML POST binding — genuinely need to land on a specific URL. Hybrid is fine. Pretending it's not happening is what gets you a sign-in surface that's 80% embedded and 20% surprises.

Where to go next

If you're trying to make this decision today, the things worth reading next:

• How OAuth 2.0 Actually Works — the redirect dance you're choosing to keep or remove.
• Why Iframe Authentication Is Difficult — if you're considering the iframe-embedded pattern.
• Secure Session Management — what happens after authentication, which is most of the work.

Embedded auth isn't a feature flag you turn on. It's a posture. It says: the user is inside our product, and they will stay inside our product, and we will do the work to make that safe. The companies that pull it off well make it look invisible. That's the goal.