SDK surfaces: React, hosted pages & embed
- Written for
- ＋ Written for
- Deprecated
- ＋ Deprecated
- Applies to
- ＋ Applies to
Atlas ships three ways to render sign-in. They drive the same server flow, so they can't diverge in what the server sees — but they differ in where they run and how much you theme. Pick by how much control you want over the DOM.
Which surface renders what
Capability |
| Hosted pages |
|
Runs in | your React app's DOM | Atlas-hosted route on your domain | any site (script tag) |
Email / password, OTP, magic link | ✓ | ✓ | ✓ |
Passkeys / WebAuthn | ✓ | ✓ | ✓ |
Themed Google button (invisible GSI overlay, id_token flow) | ✓ ( | ✓ | ✓ |
Social buttons themed via | ✓ | ✓ | ✓ |
Full appearance-token theming | ✓ | ✓ (branding) | ✓ |
Org switcher / profile / session manager | ✓ | ✓ | partial |
Zero-JS / no build step | — | ✓ | ✓ |
Cross-domain first-party session (Next.js handshake) | ✓ ( | n/a | — |
The themed Google overlay button is on all three as of @atlasauth/react@0.1.4 — none renders Google's native, unstyleable widget any more.
Theming (appearance)
All surfaces read the same design tokens + per-element class overrides. Element keys include card, headerTitle, formFieldInput, formButtonPrimary, socialButton, dividerText, footerAction, avatar, menu. Tokens (colorPrimary, colorBackground, colorText, colorBorder, borderRadius, fontFamily, spacingUnit) are exposed as --atlas-* CSS variables, so your CSS/Tailwind reaches the components and overrides append to (never replace) the base classes.
<AtlasProvider publishableKey="pk_live_…" appearance={{
variables: { colorPrimary: '#5b5bd6', borderRadius: '10px' },
elements: { socialButton: 'rounded-xl shadow-sm' },
}}>
<SignIn />
</AtlasProvider>Picking one
React SDK — you own the page and want components in your own DOM with full token theming and Next.js middleware.
Hosted pages — least code; Atlas serves the sign-in/profile UI on your custom domain, themed via branding.
Embed — drop-in widget for any stack without a build step.