Drop-in iframe authentication for your apps. Email/password, magic links, OTP, and OAuth — fully customizable with your branding. Launch in minutes.
Sign in to continue
A practical explainer for engineers evaluating identity options for their SaaS, B2B dashboard, or white-label product.
Embedded authentication is a pattern where the login experience lives inside your application — typically rendered through an iframe, a web component, or a UI SDK — rather than redirecting users to a separate identity provider domain. Your user never leaves yourapp.com. They type their email, click the magic link, finish OAuth, and stay on your page the entire time. The auth provider hands a signed token back to your application through a secure cross-origin channel, and your app takes it from there.
The alternative is hosted login — the model popularized by Auth0, Okta, and most enterprise IAM vendors. With hosted login, your application redirects the browser to auth.yourprovider.com, the user authenticates there, and the provider redirects them back with an authorization code. It is the safest pattern for credentials — there is no way for your application code to ever see a password — and it is what every OAuth 2.0 textbook recommends. But it comes with real ergonomic costs.
Hosted login breaks the visual continuity of your product. The login page lives on a different domain, with a different URL bar, a different favicon, and frequently a different look-and-feel no matter how carefully you theme it. Single-page applications that want to keep a user in-place — modals, drawers, embedded widgets, white-label dashboards — cannot use a redirect-based flow without unmounting their entire UI state. And for white-label products specifically, sending an end-user to a third-party domain is a deal-breaker: the customer is paying you to look like a first-party experience.
Embedded auth solves the UX problem. The iframe loads the provider's login page, but the user perceives it as part of your app. The frame is fully themable. Forms post directly to the provider, so credentials still never touch your servers. When authentication succeeds, the iframe sends a postMessage back to the parent page containing a signed JWT, and your front-end uses it to make authenticated API calls.
The trade-off is implementation complexity for the provider. Doing embedded auth correctly means solving the third-party-cookie problem, handling postMessageorigin validation correctly, isolating the auth context inside an iframe so a compromised parent page can't exfiltrate credentials, and managing refresh tokens without exposing them to the embedding application. This is exactly what AuthFrame is built for — the provider absorbs the hard parts, and you get a one-line embed.
Developers reach for embedded auth in three common situations. First, when conversion matters: a redirect costs you a measurable percentage of signups, especially on mobile where the bounce-back loop is jarring. Second, when the product is itself an embed — a widget, a chat box, a checkout extension — and a full-page redirect would break the parent application's state. Third, when the product is white-labeled: a B2B dashboard sold to enterprises that need their end-users to never see a vendor's domain. In all three cases, the redirect-based hosted flow is the wrong tool, and an embeddable authentication surface is the right one.
AuthFrame is opinionated about this. We don't ask you to choose between embedded and hosted — we treat embedded as the primary mode and design every feature around it. The iframe surface, the postMessage protocol, the JWKS endpoint, the theming engine, the multi-tenant isolation model: all of it exists so you can put auth inside your product without writing the cross-origin plumbing yourself.
How a request flows from the embedded iframe through token exchange to an authenticated API call — and the isolation guarantees at each hop.
The login surface runs on a separate origin from your application. Browser same-origin policy prevents the parent from reading the iframe's DOM, cookies, or localStorage. A compromised parent page cannot read what the user typed into the login form. The iframe is served with a strict CSP andX-Frame-Optionsis replaced by per-tenantframe-ancestorsrules.
Access tokens are RS256-signed JWTs with a 15-minute default lifetime. They includesub,aud,iss, and tenant claims. Verification is stateless: your API fetches the public JWKS once, caches it, and verifies signatures locally. No round trips back to AuthFrame on the hot path.
Refresh tokens live in HttpOnly, Secure, SameSite=None cookies scoped to the AuthFrame origin. JavaScript in the parent page cannot read them. To work around third-party cookie restrictions in modern browsers, AuthFrame supports CNAME-based custom domains so the auth iframe loads fromauth.yourapp.com, keeping cookies first-party.
Sessions follow the rolling-refresh pattern. The iframe silently calls /refreshahead of token expiry, rotates the refresh token (one-time-use), and posts the new access token to the parent. Logout revokes the refresh family server-side, so a stolen refresh token can't outlive an explicit signout across devices.
Every postMessage from the iframe is sent with an explicit target origin (never "*") and includes a signed nonce. The parent SDK verifies the message origin matches the configured auth domain and that the nonce matches its outstanding request. Allowed parent origins are configured per-application — a stolen client ID cannot be rendered from an arbitrary domain.
The browser is actively hostile to most of what embedded authentication needs to do. Here's the terrain.
Same-origin policy is the foundation of web security — and the main obstacle to embedding anything that needs identity. Cross-origin iframes can't read parent state, can't share cookies by default, and modern browsers increasingly enforceSameSite=Laxas the default for cookies, breaking naive cross-site session models. Working with these restrictions (instead of trying to defeat them) is the entire game.
Safari (ITP) and Firefox (ETP) already block third-party cookies by default. Chrome is rolling out the same. Any auth provider relying on a session cookie set on its own domain — read from inside a cross-site iframe — is on borrowed time. The fix is CNAME-based first-party deployment, but doing that securely requires automated TLS provisioning, per-tenant certificate management, and careful origin pinning.
OAuth 2.0 has a redirect-based mental model baked in. Doing a Google or GitHub sign-in from inside an iframe means popping a new window (because Google explicitly blocks framing of accounts.google.com), running PKCE, catching the redirect on a callback page, and posting the code back to the original iframe. Each provider has quirks — Apple Sign-In requires form_post response mode, Microsoft requires nonce handling, GitHub doesn't support PKCE confidentially.
Every UX shortcut chips away at the security boundary. Storing access tokens in localStorage makes XSS catastrophic. Exposing refresh tokens to JavaScript makes them stealable. Loosening frame-ancestors to a wildcard opens clickjacking. The right answer is rarely the simple one: HttpOnly cookies for refresh, short-lived access JWTs in memory, strict origin allowlists, and a refusal to ship features that require relaxing any of it.
The honest version:most of the engineering work in an auth provider isn't the login form — it's the cross-origin choreography, the cookie strategy, the OAuth quirks, and the constant browser-vendor moving target. That's the work AuthFrame absorbs so your team doesn't have to.
Where embedded auth pays off the most.
Modern web apps that want a polished login experience without redirecting users off-domain. Email/password, magic links, and social — all themed to match the product.
Internal-facing customer dashboards where SSO, RBAC, and audit logs matter. Embedded auth keeps the dashboard feeling integrated rather than bolted-on.
Chat boxes, support widgets, checkout extensions, and other surfaces that live inside someone else's page. A full-page redirect would break the host application.
Software resold under your customer's brand. The end-user must never see a vendor domain. CNAME-based custom domains keep auth on the customer's subdomain.
Customer or vendor portals that need SAML SSO, SCIM provisioning, and per-tenant configuration. One AuthFrame app per enterprise customer, with isolated user pools.
Platforms where each merchant or workspace needs its own user pool and branding. AuthFrame's multi-tenant model gives every tenant isolated users, themes, and audit trails.
A direct comparison against the three most common identity options. We've tried to be fair — every product here has things it does well.
| Capability | AuthFrame | Auth0 |
|---|---|---|
| Embedded iframe (first-class) | Primary mode | Universal Login is hosted |
| Hosted login redirect | ||
| CNAME custom domains | Paid tier only | |
| Multi-tenant (orgs / apps) | ||
| RS256 JWTs + JWKS endpoint | ||
| Theming via tokens + CSS | Branding API + limited CSS | |
| SAML SSO | Roadmap | |
| Pricing predictability | Flat per-app | MAU-based, grows fast |
| Lock-in surface | Open data export |
| Capability | AuthFrame | Clerk |
|---|---|---|
| Framework-agnostic embed | React-first SDK | |
| Iframe-based isolation | UI components run in-page | |
| React / Next.js components | React wrapper available | |
| White-label / brand removal | Paid tier | |
| JWT verification via JWKS | ||
| Self-hostable | ||
| Pricing for high-volume MAU | Flat tiers | MAU-priced |
| Capability | AuthFrame | Firebase Auth |
|---|---|---|
| Embedded iframe UI | FirebaseUI is in-page only | |
| Vendor-neutral (no GCP lock-in) | ||
| Multi-tenant per-app branding | Identity Platform tier | |
| Hostable custom domains | ||
| OIDC / SAML support | Identity Platform tier | |
| Tight integration with Firestore / FCM | ||
| Per-app theming dashboard |
Powerful auth features, zero backend work.
Add an iframe to your HTML and listen for postMessage events. That's it.
Match your brand with theme tokens, custom CSS, live iframe preview, and 6 built-in presets.
Industry-standard signed tokens. Verify with our public JWKS endpoint.
One dashboard, unlimited apps. Each with its own users, themes, and settings.
Email/password, magic links, OTP, Google OAuth, GitHub OAuth — toggle per app.
Rate limiting, brute-force protection, audit logs, encrypted secrets, CSP headers.
Answers to the questions engineers actually ask when evaluating an embedded auth provider.