Drop-in iframe authentication for your apps. Email/password, magic links, OTP, and OAuth — fully customizable with your branding. Launch in minutes.
Welcome back
Sign in to continue
What a working integration involves, with a link to the guide that covers each step in detail.
Sign up for free and create an app in the dashboard. You get a client ID, and you choose which sign-in methods the widget offers.
Getting startedList the domains your site runs on. The widget only hands tokens to pages on those domains, so a copied embed code is useless elsewhere.
Events referencePaste one iframe and add a message listener. Ready-made components for React, Next.js and Vue handle resizing and events.
React guideCheck each token's RS256 signature against the JWKS endpoint, then start your own session. No SDK is needed on the server.
Verify in Node.jsNew to embedded authentication? Read What Is Embedded Authentication?, browse the blog, or see how EmbedAuth compares with the alternatives.
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 postMessage origin validation correctly, isolating the auth context inside an iframe so a compromised parent page can't read credentials as they are typed, and handing tokens only to the sites the application has approved. This is exactly what EmbedAuth 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 is one more step where a sign-up can be abandoned, 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.
EmbedAuth 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, so a compromised parent page cannot read what the user types into the login form. The widget is served with a Content-Security-Policy that refuses every script except its own bundle and, when you enable it, Google's reCAPTCHA.
Access tokens are RS256-signed JWTs with a one-hour default lifetime. They includesub,aud,iss, and the app's client ID. Verification is stateless: your API fetches the public JWKS once, caches it, and verifies signatures locally. No round trips back to EmbedAuth on the hot path.
Sign-in doesn't depend on a cookie set inside the frame. The widget hands its result to your page as a postMessage, so third-party cookie blocking in Safari, Firefox and Chrome doesn't get in the way. What happens next is yours to decide: keep the tokens in memory, or exchange them for a first-party session on your own domain.
Refresh tokens are single-use. Posting one to /refresh returns a new access token and a new refresh token, and the old one stops working. If a spent token is ever presented again, EmbedAuth revokes the whole token family — so when a refresh token is copied, the session ends as soon as both copies are used. Sessions can also be revoked one by one from the dashboard.
Once you list your app's domains, the message that carries tokens is posted with an explicit target origin — never "*" — and only to a page on one of those domains. A client ID copied onto someone else's site renders the form but hands its tokens to nobody. Your page should still check event.origin before trusting any message.
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) blocks third-party cookies by default, Firefox partitions them per site, and Chrome lets users block them. Any auth provider relying on a session cookie set on its own domain — read from inside a cross-site iframe — breaks for many of their users. The way out is not to depend on that cookie at all: pass the result of sign-in to the parent page as a message, and let the application keep its own first-party session.
OAuth 2.0 has a redirect-based mental model baked in. Doing a Google sign-in from inside an iframe means popping a new window (because Google refuses to be framed), running PKCE, catching the redirect on a callback page, and getting the result back to the original iframe. Each provider has its own quirks — which flows it supports, which profile fields it returns, and whether it says the email address is verified.
Every UX shortcut chips away at the security boundary. Storing tokens in localStorage makes XSS catastrophic. Posting tokens to any page that frames the form hands them to whoever copies your embed code. Loosening script-src to allow inline scripts turns injected markup into running code. The right answer is rarely the simple one: short-lived access tokens, refresh tokens that rotate on every use, 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 EmbedAuth 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.
Customer-facing dashboards and admin consoles that should feel like one product. The sign-in form matches your UI, and auth events and audit logs show who signed in and when.
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 form sits inside the customer's page with no EmbedAuth branding, and transactional emails carry the app's own brand name.
Portals for suppliers, partners or customers, where each audience gets its own app: a separate user pool, separate branding and its own allowed domains.
Platforms where each merchant or workspace needs its own user pool and branding. EmbedAuth's multi-tenant model gives every app isolated users, themes and auth event history.
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 | EmbedAuth | Auth0 |
|---|---|---|
| Embedded iframe (first-class) | Primary mode | Universal Login is hosted |
| Hosted login redirect | Embed-first | |
| Custom domains | ||
| Multi-tenant (orgs / apps) | ||
| RS256 JWTs + JWKS endpoint | ||
| Theming via settings + CSS | Branding API + limited CSS | |
| SAML SSO | ||
| MFA / passkeys | ||
| Pricing predictability | Flat tiers | MAU-based |
| Capability | EmbedAuth | Clerk |
|---|---|---|
| Framework-agnostic embed | React-first SDK | |
| Iframe-based isolation | UI components run in-page | |
| React / Next.js components | Copy-paste examples in the docs | |
| White-label / brand removal | Paid tier | |
| JWT verification via JWKS | ||
| MFA / passkeys | ||
| Pricing for high-volume MAU | Flat tiers | MAU-priced |
| Capability | EmbedAuth | Firebase Auth |
|---|---|---|
| Embedded iframe UI | FirebaseUI is in-page only | |
| Vendor-neutral (no GCP lock-in) | ||
| Multi-tenant per-app branding | Identity Platform tier | |
| Custom domains | ||
| OIDC / SAML support | Google & Discord OAuth | 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 settings, custom CSS, a live preview and a gallery of preset themes.
Industry-standard signed tokens. Verify with our public JWKS endpoint.
One dashboard, many apps. Each with its own users, themes, and settings.
Email/password, magic links, email OTP, Google OAuth, Discord OAuth — toggle per app.
Rate limiting, account lockout, audit logs, encrypted secrets, CSP headers.
Answers to the questions engineers actually ask when evaluating an embedded auth provider.