Embedded Login vs Hosted Login: Choosing a Safer Customer Sign-in

Where the customer types their credentials decides who can see them, how easily the page can be imitated, and whether passkeys and single sign-on work at all. Customer identity (CIAM) teams choose between a hosted login, where the app redirects to a sign-in page served by the identity provider on its own origin, and an embedded login, where the app renders the form itself and passes credentials or tokens to the provider through an SDK, API or iframe. The choice looks like a design decision but it changes the threat model: credential exposure, phishing resistance, clickjacking, cross-origin cookie behaviour and the OAuth grants you are allowed to use. This guide is for CIAM architects, application security engineers and product owners. It builds on the Customer IAM (CIAM) Guide and goes deeper on this one decision.

Key takeaways

• Hosted login is the secure default. The credential never touches application code, the OAuth Authorization Code flow with PKCE applies cleanly, and the IETF best current practices for native and browser-based apps are written around it.
• Embedded login moves credential handling into your app. Every script on the page, every SDK version and every logging pipeline becomes part of the credential path, and password-based embedded flows often rely on the password grant, which RFC 9700 says must not be used.
• Native apps must not use embedded web views for OAuth. RFC 8252 (BCP 212) requires an external user agent, because a host app can record keystrokes and copy session cookies from a web view.
• Passkeys reduce the phishing gap but not the code exposure gap. WebAuthn binds the credential to the relying party ID, so a look-alike page cannot use it in either model; embedded passkey sign-in still needs correct RP ID, iframe permissions or app-to-domain association.
• Cross-origin login frames are fragile and risky. Third-party cookie blocking breaks silent iframe authentication, and an identity provider page that can be framed is exposed to clickjacking.

The two models defined

• Hosted login (also called redirect, universal or centralised login): the app sends the user to the identity provider's authorisation endpoint, for example https://login.example.com/authorize. The provider renders the sign-in page, runs MFA, passkey and recovery flows, and returns an authorisation code to the app's registered redirect URI. The app exchanges the code (with a PKCE verifier) for tokens. Branding is applied through templates or a custom domain.
• Embedded login (also called in-app, native or custom UI login): the app renders its own form. Variants include: a JavaScript SDK that posts credentials from the app's origin to the provider's API; a provider widget loaded inside an iframe on the app page; a native mobile screen calling the provider's authentication API; and, worst of all, a web view inside a native app that loads the provider's page while the app retains control of it.

Some providers also offer a pop-up variant of hosted login. A pop-up keeps the provider's origin and address bar, so it behaves like hosted login for security purposes, but it depends on window messaging between origins, which must check the sender's origin.

Side-by-side comparison

Threat model: hosted login

• Look-alike domains: because users are trained to one login domain, attackers register similar domains and proxy the real page (adversary-in-the-middle phishing, ATT&CK T1557 and T1056.003). Password and OTP are captured and relayed; session cookies can be stolen (T1539). Hosted login does not stop this on its own; phishing-resistant authenticators do.
• Redirect URI abuse: loosely matched redirect URIs or open redirects on the app let an attacker receive the authorisation code. Use exact string matching for registered redirect URIs and fix open redirects; see the Open Redirect Guide.
• Custom domain hygiene: a branded login domain (login.brand.com) pointed at the provider by CNAME becomes a subdomain takeover target if the tenant is deleted and the record stays. See the Subdomain Takeover and Dangling DNS Guide.
• Template injection: custom HTML and script added to hosted templates runs on the login origin. Keep templates minimal and under change control; avoid third-party analytics on the login page, in line with RFC 9700's advice that the authorisation endpoint should not include third-party resources.

Threat model: embedded login

• Credential exposure in the app: any script on the page can read form fields. A compromised analytics tag, tag manager or npm dependency becomes a credential skimmer. Content Security Policy and Subresource Integrity help but must be strict on the login route; see the Content Security Policy Guide.
• Password grant and proprietary APIs: RFC 9700 states the resource owner password credentials grant exposes the user's credentials to the client and must not be used. Proprietary "authenticate with username and password" endpoints carry the same exposure and are directly reachable by credential stuffing tools, bypassing any front-end challenge.
• Native web views: RFC 8252 Section 8.12 states that native apps must not use embedded user agents for authorisation requests, because the host app can record keystrokes, submit forms to bypass consent and copy session cookies, users cannot verify the site without an address bar, and there is no shared SSO state with the browser. Authorisation servers may detect and block such requests.
• Iframe widgets: a framed login is subject to clickjacking unless the provider restricts which origins may frame it with CSP frame-ancestors. Silent token renewal in hidden iframes also lets injected script obtain fresh tokens; RFC 10017 notes that short token lifetimes, refresh token rotation and DPoP do not stop this.
• Token storage: embedded single-page apps that receive tokens in the browser store them where cross-site scripting can reach them. See the Browser Storage Security Guide.

Passkeys in each model

NIST SP 800-63B-4 defines phishing resistance as keeping authenticator outputs away from an impostor verifier without relying on the user's vigilance, and names WebAuthn as an example of verifier name binding: the authenticator selects its key based on the authenticated domain name. That property holds whichever model you choose, so passkeys close most of the phishing gap that hosted login only narrows. The integration differs.

For protocol detail see the FIDO2 and WebAuthn Internals Guide, and plan recovery before rollout with Passkey account recovery.

Cross-origin and session issues

• Third-party cookies: Safari has blocked cookies for cross-site resources by default since Safari 13.1 and iOS 13.4 (March 2020), recommending a first-party session or the Storage Access API instead. Any embedded design that relies on the provider's cookie inside an iframe on the app's domain will fail silently in such browsers. RFC 10017 notes that third-party cookie blocking has made refresh tokens more attractive for browser apps, which raises the stakes on their storage.
• Window messaging: pop-up and iframe flows return results by postMessage. Receivers must check the event origin against an exact allow list and senders must name the target origin, never "*".
• CORS on authentication APIs: embedded SDKs call the provider's API cross-origin, so the provider must allow the app's origin. Wildcard or reflected origins with credentials let any site drive the API; see the CORS Misconfiguration Guide.
• Session architecture: RFC 10017, OAuth 2.0 for Browser-Based Applications (published in August 2026 per the IETF datatracker, checked November 2026), strongly recommends a backend for frontend (BFF) that keeps tokens server-side behind HttpOnly, Secure cookies with CSRF protection. The BFF pairs naturally with hosted login. See the OAuth for Browser-Based Applications and the BFF Pattern Guide.
• Federated sign-in buttons: browsers are replacing iframe and third-party cookie based federation with FedCM; see FedCM.

Decision criteria

• Choose hosted login when: you have more than one app or channel sharing accounts, you want passkeys and new MFA methods without per-app work, you handle sensitive data (health, finance, identity documents), or your app teams do not own a security review process for front-end dependencies.
• Choose embedded login when: there is a single app with a strong conversion case for in-page sign-in, the team can run strict CSP and dependency control on the login route, authentication is passkey-first so no reusable secret is typed, and the provider's API offers server-side bot and risk controls equal to its hosted page.
• Never choose: a web view login inside a native app, or the password grant for new builds.
• Native apps: use the system browser session (for example the platform's authentication session or custom tab APIs) for hosted login, or the platform passkey API for an embedded passkey screen. See the OAuth for Native and Mobile Apps Guide.
• Small versus large organisations: a small team gains most from hosted login because security fixes arrive without engineering effort. Large organisations with a dedicated identity engineering team sometimes build embedded flows for flagship apps while keeping hosted login for everything else; the risk is that the embedded path becomes the weakest link that attackers target.

Worked scenario: a retailer with web, iOS and Android apps

A retailer has a web shop, two mobile apps and a loyalty site on a separate brand domain. Marketing wants an in-page login on the web shop to reduce drop-off; the security team wants passkeys and fewer credential stuffing incidents.

1. Baseline: the web shop uses an embedded SDK posting passwords to the provider API; the mobile apps load the provider page in a web view; the loyalty site has its own password database. Credential stuffing hits the API directly, bypassing the web shop's challenge.
2. Decision: move all channels to hosted login on login.retailer.example as the single RP ID, using Authorization Code with PKCE. The mobile apps switch from web views to the system browser session. The loyalty site becomes a client of the same provider.
3. Passkeys: register passkeys on login.retailer.example; publish a related origins file so the loyalty brand domain can use the same passkeys; declare both mobile apps for the login domain so native passkey prompts work.
4. The conversion concern: the hosted page uses the brand's custom domain and templates with no third-party scripts, and passkey autofill makes return sign-in a single prompt, recovering most of the drop-off argument.
5. Clean-up: disable the password API grant for the web shop client, set CSP frame-ancestors 'none' on the login page, and monitor for any client still calling the retired endpoint.

The 23andMe incident shows why the endpoint matters: an attacker matched reused credentials against more than 18,000 accounts while MFA was optional; see the 23andMe credential stuffing breach.

Implementation and rollback

1. Inventory clients: list every app, its login model, grant type, SDK version and redirect URIs.
2. Harden the hosted page first: custom domain with CAA and DNS monitoring, no third-party scripts, CSP with frame-ancestors 'none', exact redirect URI matching.
3. Migrate one client at a time: start with the lowest traffic app; run hosted and embedded paths side by side behind a feature flag, comparing completion rates and support tickets for two to four weeks.
4. Retire legacy grants: once traffic on the old path drops to zero, disable the password grant and proprietary authentication endpoints for that client.
5. Introduce passkeys: offer creation after a successful sign-in, then enable passkey autofill.
6. Rollback: keep the feature flag and the old client configuration for one release cycle; existing sessions and refresh tokens survive a flag flip, so users are not forced to sign in again.

Detection and measurement

• Log: grant type per client, failed sign-ins by source and username, sign-ins from unregistered origins or redirect URIs, postMessage origin rejections, CSP violation reports on the login route, and passkey registration and use.
• Alert on: any use of the password grant after retirement, spikes of failures spread across many accounts (credential stuffing), and new origins added to CORS or related origins lists outside change control.

Metrics:

• Percentage of sign-ins through Authorization Code with PKCE (target: 100 percent).
• Number of clients with the password grant or proprietary credential endpoints enabled (target: zero).
• Percentage of active accounts with a passkey, and percentage of sign-ins using one.
• Account takeover reports per 100,000 active accounts, month on month.
• Sign-in completion rate by channel before and after migration.

Framework mapping

Common failure patterns

• Front-end challenge, open API: the embedded form has a CAPTCHA but the API it calls does not, so credential stuffing tools skip the form. See the Password Spraying and Credential Stuffing Defence Guide.
• Web views kept for "consistent branding": native apps keep loading the provider page in a web view, giving up SSO and exposing credentials to the app process.
• Analytics on the login page: a session replay or tag manager script on an embedded or hosted login route records keystrokes into a third-party service.
• Framable login widgets: frame-ancestors set to * so the widget works everywhere, which lets any site overlay it. See the Clickjacking Guide.
• RP ID chosen by accident: passkeys created on a temporary or provider-owned domain cannot follow a later move to the brand domain, forcing re-enrolment.
• Silent iframe renewal assumed to work: sessions break in browsers that block third-party cookies, and teams respond by storing long-lived tokens in local storage.

Practitioner checklist

• Default every new customer app to hosted login with Authorization Code and PKCE.
• Ban web view login in native apps; use the system browser session or the platform passkey API.
• Disable the password grant and proprietary credential endpoints for every client that does not need them.
• Choose the passkey RP ID deliberately, and use related origins for additional brand domains.
• Set CSP frame-ancestors on the login page, and remove third-party scripts from all login routes.
• Apply bot and rate controls at the authentication API, not only the form.
• Check postMessage origins and CORS allow lists against exact values.
• Keep tokens server-side with a BFF for browser apps.
• Track grant types, passkey adoption and takeover rates monthly.

Standards and references

• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 8252 OAuth 2.0 for Native Apps
• IETF: OAuth 2.0 for Browser-Based Applications (RFC 10017)
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• W3C: Web Authentication Level 3
• OWASP: Clickjacking Defense Cheat Sheet
• WebKit: Full Third-Party Cookie Blocking and More

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · CIAM Buyer's Guide · Passwordless and Passkeys Guide · Account Takeover Prevention Guide · OAuth for Native and Mobile Apps Guide