Choosing Between Hosted and Embedded Login: The Trade-Off Nobody Explains

Two integration shapes, one decision that's hard to reverse

Every product wiring up authentication through a third party ends up choosing between two shapes. Hosted login redirects the browser to a page controlled entirely by the identity provider (typically an OpenID Connect authorization code flow with PKCE) where the user authenticates, and the browser is redirected back with proof of that authentication. Embedded login keeps the user inside the product's own domain the entire time, rendering the credential form through a vendor SDK or API calls the product's own frontend makes directly. Both work. Both look clean in a demo. The decision between them is expensive to reverse once it's made, because sessions, cookies, bookmarked URLs, and user habits all end up shaped around whichever one you picked, and migrating live users off one flow onto the other is its own project.

What hosted actually buys you

The mechanism matters more than the redirect. When a browser is sent to the identity provider's own origin, the credential is typed into a page that origin controls end to end: its content, its scripts, its headers, its response to a new attack technique discovered next month. That means the provider can ship a fix, add a detection rule, or roll out a new MFA method without your team shipping anything, because the surface where credentials are entered was never part of your deployment. It also means your product's own origin never touches a raw credential at any point: not in its JavaScript, not in a request your frontend makes, not in memory your application code can reach. A cross-site scripting vulnerability anywhere in your product, however it got there, cannot become a credential-theft vulnerability, because the credential was never present on a page your product served.

What embedded actually buys you

The appeal of embedded login is real: full control over presentation, a form that looks exactly like the rest of the product, no visible domain change to explain to users. The price for that control is that your application's own origin now has a direct relationship to the credential (either your frontend submits it, or your backend proxies it), which means your content security policy, every third-party script running on that page, and your own application's exposure to injection vulnerabilities are now security-relevant to authentication in a way they simply are not under a hosted flow. A single script-injection bug anywhere on that page, introduced by your own code or a dependency you didn't audit closely enough, becomes a live path to stealing credentials as they're typed. That's not a hypothetical trade; it's the direct consequence of choosing to host the input yourself.

The honest framing: whose attack surface do you trust more

Neither option is universally correct, and any framing that says otherwise is selling one over the other rather than helping you decide. A team with a small, disciplined frontend, tight control over its dependencies, and a strong product reason to own every pixel of the login experience can run embedded safely, provided the SDK it's built on is actually designed for that, meaning short-lived, single-use tokens exchanged server-side rather than long-lived secrets sitting in browser-accessible storage. A team that can't realistically audit every third-party script that ends up on its pages, or that would simply rather the credential surface be owned by a specialist with a narrower, more scrutinized job, is safer choosing hosted and accepting the redirect.

The middle option people forget to mention

The hosted-versus-embedded framing sometimes skips a third shape that isn't really a compromise so much as a different split of responsibility: a backend-for-frontend pattern, where the browser still talks to a page your product serves, but that page never handles the credential directly: it hands off to the identity provider server-side, and the only thing that ever reaches the browser is a session artifact issued after authentication is already complete. This gets you a login experience that can look and feel continuous with your product, closer to what embedded promises, without your frontend JavaScript ever being in the credential's path. The cost is real too: you now own a server-side component that has to be built and operated correctly, with its own review burden, and a mistake there is just as capable of leaking a session as a frontend mistake is of leaking a password. It's not a way to get hosted's guarantees for free: it's a different place to put the discipline, and it only pays off if your backend is genuinely the surface you trust more than your frontend.

What to test before you commit

Whichever shape you pick, verify it under the conditions that actually matter rather than the happy path a vendor's quickstart walks through. Confirm what a token looks like in the browser's storage and how long it lives there: a long-lived credential sitting in local storage is a materially worse position than a short-lived one that's rotated frequently, regardless of which integration shape produced it. Check what your own content security policy would need to allow for the integration to work, and whether that loosening creates an opening elsewhere. Test what happens when the identity provider is briefly unreachable: does your login experience fail closed with a clear message, or does it fail in some undefined state that's harder to reason about during an actual incident. None of this shows up in a demo, because a demo is built around everything working. It's the same discipline as evaluating any other vendor claim: ask what happens on a bad day, not a good one.

The redirect isn't the enemy

The most common objection to hosted login is that a redirect hurts conversion or feels unpolished, and it's worth pushing back on that directly. A visible domain change, at the moment someone is asked for a credential, is informative: to a security-conscious user, and even more so to anyone who's been trained by years of phishing-awareness advice to check the address bar before typing a password. That's the same reason browsers surface the domain prominently in the address bar during a sensitive action: it's a legitimate trust signal, not friction to be engineered away. A slicker embedded flow that hides the domain change trains users to stop checking it, which is precisely the habit that makes phishing work in the first place. Optimizing that signal away for a marginal conversion gain is optimizing against the exact behavior you want your users to have.

Where we come down on it

Hosted login is our default supported path, for the reasons above: it keeps the credential surface off every product built on top of us, regardless of what that product's own frontend looks like or who wrote it. The redirect does not have to look generic: tenant branding lets the hosted page carry a tenant's own visual identity while custom login domains remain in progress. That's the version of 'control over presentation' we think is worth having: you get to shape what the user sees, without taking on what the user types.

Ask yourself which surface you can actually defend

The right choice depends on which attack surface your team is actually equipped to defend, not on which flow feels more native in a demo. Ask honestly whether your frontend's dependency list, your review process, and your incident response are strong enough to own a credential surface directly, and if you're not sure, that uncertainty is itself the answer.

It's also worth revisiting the decision on a schedule rather than treating it as permanent. A team that chose embedded early, when its frontend was small and every dependency was reviewed by hand, may have a very different dependency graph two years and several redesigns later: more third-party scripts, more analytics tags, more surface nobody on the current team fully audited. The question 'do we still trust this surface with a credential' is worth asking again as the product changes, not just once at integration time.