Documentation
1Auth docs for multi-tenant authentication
This root-domain docs hub is the stable public reference for 1Auth. It covers setup, flows, API behavior, security controls, tenancy, operational troubleshooting, and a 36-page SEO library for feature, comparison, use-case, and implementation queries without depending on the separate docs host.
Ship a working auth flow with app-scoped routes and token exchange.
Magic links, OAuth, passkeys, email verification, and password reset.
The public endpoints, callback expectations, and token lifecycle.
The controls that matter for multi-tenant auth in production.
How 1Auth keeps apps isolated while sharing one backend.
Where 1Auth differs from Auth0, Clerk, and Supabase Auth.
SEO Library
36 search-intent pages for features, comparisons, use cases, and implementation
This library is built for high-intent queries around modern app authentication. It covers commercial comparisons, product architecture, developer implementation, and the security controls that buyers validate before rollout.
Features
8 pagesProduct pages for the auth primitives and operational features teams evaluate first.
Comparisons
7 pagesAlternative and migration pages for teams actively comparing providers or replacing a current stack.
Use Cases
7 pagesApplication-specific pages for B2B SaaS, internal tools, admin panels, AI tools, and client portals.
Security
5 pagesTechnical trust pages around JWTs, rotation, encryption, auditability, and auth hardening.
Guides
6 pagesImplementation pages for building and self-hosting a production auth backend.
Developers
3 pagesReference pages for the API, JWKS verification, and Python integration paths.
Featured Pages
Highest-intent SEO and GEO landing pages
These pages target the most commercial and architecture-heavy questions around 1Auth.
Run one authentication backend across many apps while keeping users, tokens, organizations, and roles isolated per app.
Keep the same email address isolated across separate apps so users, roles, providers, and tokens never merge by accident.
Ship passwordless email sign-in with short-lived tokens, secure callback handling, and app-scoped session exchange.
Add WebAuthn passkeys to your auth backend without giving up app-scoped isolation, recovery flows, or fallback methods.
Add organizations, memberships, invitations, and teams to auth without breaking app boundaries or operational clarity.
Compare 1Auth vs Auth0 when you want a self-hosted, backend-first auth platform with separate identity per app instead of a shared directory model.
Compare 1Auth vs Clerk when you want backend-first auth ownership, per-app isolation, and self-hosted control across multiple products.
Compare 1Auth vs Supabase Auth when you need one auth backend across multiple apps instead of tying identity to separate project boundaries.
Handle B2B SaaS identity with organizations, teams, invitations, secure admin operations, and separate identity per app.
Support several independent products from one auth backend without forcing shared accounts, shared providers, or accidental SSO.
Review the critical controls for a production auth backend: app isolation, JWT validation, callbacks, rotation, recovery, and operational hardening.
Plan and ship a SaaS auth backend with app-scoped users, secure token exchange, recovery flows, provider support, and day-two operations.
Run authentication in your own infrastructure with control over keys, storage, providers, auditability, and app-scoped identity boundaries.
Features
Features pages built for real buying and implementation queries
Product pages for the auth primitives and operational features teams evaluate first.
Run one authentication backend across many apps while keeping users, tokens, organizations, and roles isolated per app.
Keep the same email address isolated across separate apps so users, roles, providers, and tokens never merge by accident.
Ship passwordless email sign-in with short-lived tokens, secure callback handling, and app-scoped session exchange.
Support classic email and password sign-in with reset flows, verification, rate limiting, and app-scoped user separation.
Add WebAuthn passkeys to your auth backend without giving up app-scoped isolation, recovery flows, or fallback methods.
Support Google, GitHub, and Apple OAuth across multiple apps without collapsing everything into one shared provider configuration.
Add organizations, memberships, invitations, and teams to auth without breaking app boundaries or operational clarity.
Operate auth safely with per-app user views, settings management, audit visibility, and secure day-two workflows.
Comparisons
Comparisons pages built for real buying and implementation queries
Alternative and migration pages for teams actively comparing providers or replacing a current stack.
Compare 1Auth vs Auth0 when you want a self-hosted, backend-first auth platform with separate identity per app instead of a shared directory model.
Compare 1Auth vs Clerk when you want backend-first auth ownership, per-app isolation, and self-hosted control across multiple products.
Compare 1Auth vs Stytch when you want passwordless and OAuth flows inside one app-scoped auth backend with stronger multi-product ownership.
Compare 1Auth vs Supabase Auth when you need one auth backend across multiple apps instead of tying identity to separate project boundaries.
Compare 1Auth vs Firebase Auth when you want a dedicated auth backend with per-app isolation, self-hosted control, and product-specific operations.
Compare 1Auth vs WorkOS when you need product auth, app-scoped users, and self-hosted control instead of focusing mainly on enterprise identity infrastructure.
Compare 1Auth vs Better Auth when you want a dedicated auth backend for multiple apps instead of embedding auth logic into each product codebase.
Use Cases
Use Cases pages built for real buying and implementation queries
Application-specific pages for B2B SaaS, internal tools, admin panels, AI tools, and client portals.
Build a SaaS auth stack with OAuth, magic links, password flows, recovery, admin operations, and app-scoped token boundaries.
Handle B2B SaaS identity with organizations, teams, invitations, secure admin operations, and separate identity per app.
Support several independent products from one auth backend without forcing shared accounts, shared providers, or accidental SSO.
Secure internal apps with controlled access, auditability, deactivation workflows, and self-hosted auth infrastructure.
Protect admin panels with stronger auth, scoped roles, audit logging, and secure account operations.
Use conversion-friendly auth for AI tools with magic links, OAuth, app-scoped users, and a backend that can support several products over time.
Build client portal auth with separate customer access, recovery flows, role-aware operations, and app-scoped isolation.
Security
Security pages built for real buying and implementation queries
Technical trust pages around JWTs, rotation, encryption, auditability, and auth hardening.
Use RS256 JWTs, JWKS, issuer checks, audience validation, and app_id enforcement to keep multi-app auth verifiable and isolated.
Protect long-lived sessions with single-use refresh tokens, family-based revocation, and short-lived access tokens.
Store OAuth provider tokens more safely with encryption at rest, app-scoped credentials, and strict callback handling.
Track auth events, support actions, deactivations, and token lifecycle changes with a queryable audit trail.
Review the critical controls for a production auth backend: app isolation, JWT validation, callbacks, rotation, recovery, and operational hardening.
Guides
Guides pages built for real buying and implementation queries
Implementation pages for building and self-hosting a production auth backend.
Plan and ship a SaaS auth backend with app-scoped users, secure token exchange, recovery flows, provider support, and day-two operations.
Implement passwordless magic-link auth in FastAPI with secure callback handling, token expiry, and exchange-based session delivery.
Implement Google OAuth in FastAPI with PKCE, state validation, strict redirect matching, and app-scoped account linking.
Implement GitHub OAuth in FastAPI with safe callback handling, app-scoped provider linking, and clean session issuance.
Design multi-tenant auth around app boundaries, explicit token scope, and operational clarity instead of bolting tenant labels onto a shared user table.
Run authentication in your own infrastructure with control over keys, storage, providers, auditability, and app-scoped identity boundaries.
Developers
Developers pages built for real buying and implementation queries
Reference pages for the API, JWKS verification, and Python integration paths.
Integrate 1Auth into Python services with app-scoped JWT verification, JWKS validation, and a thinner auth integration surface.
Use a FastAPI-based authentication API with app-scoped routes, JWT issuance, passwordless flows, OAuth, and admin operations.
Verify 1Auth-issued JWTs locally with JWKS, RS256 signatures, issuer checks, audience validation, and app-aware enforcement.
Start here
Quickstart
Use an app-specific route for every auth action. The example below requests a magic link for the wolf_banana app and sends the user back to your frontend with a short-lived exchange code.
curl -X POST "https://api.1auth.one/auth/wolf_banana/magic-link/request" \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]","redirect_url":"https://app.example.com/callback"}'
curl -X POST "https://api.1auth.one/auth/wolf_banana/token/exchange" \
-H "Content-Type: application/json" \
-d '{"code":"EXCHANGE_CODE_FROM_CALLBACK"}'- Every route is scoped by
app_id. - Exchange access tokens off-URL to avoid leaking them in browser history and logs.
- Validate issuer, audience, app_id, expiry, and signature against JWKS.
Flow reference
Authentication flows
1Auth supports magic links, email and password, passkeys, TOTP 2FA, and OAuth with Google, GitHub, and Apple. Every flow stays isolated per app, including OAuth credentials and redirect URLs.
Magic link and email flows
Tokens are short-lived, single-use, and finalized through a POST callback step.
OAuth and passkeys
Google uses PKCE, Apple uses JWT-signed client secrets, and passkeys use WebAuthn challenges.
Endpoints
API reference
The public auth surface centers on three groups: identity bootstrap, session lifecycle, and account recovery.
| Endpoint | Purpose |
|---|---|
| POST /auth/{app_id}/register | Create an app-scoped email and password account. |
| POST /auth/{app_id}/login | Start a password-based session. |
| POST /auth/{app_id}/magic-link/request | Request a passwordless sign-in email. |
| POST /auth/{app_id}/token/exchange | Swap a short-lived code for tokens. |
| POST /auth/token/refresh | Rotate refresh tokens and mint a new access token. |
| GET /.well-known/jwks.json | Expose public signing keys for local JWT validation. |
Defense in depth
Security controls
- RS256 JWTs with audience set to the requesting app_id.
- Refresh token rotation with family-based revocation.
- Account lockout after five failed attempts with a cooldown window.
- Strict redirect URL validation and trusted-proxy aware rate limiting.
- Audit logging, OAuth token encryption at rest, and passkey challenge expiry.
If you only validate the JWT signature and ignore audience or app_id, you lose the whole isolation model. The security boundary is the combination of signature, issuer, audience, and tenant scope.
Isolation model
Tenancy and app isolation
1Auth is shared infrastructure, not shared identity. The same human can register the same email in two apps and still become two unrelated users. Roles, OAuth connections, organizations, and teams remain app-scoped.
Users
Unique by app_id plus email.
Tokens
JWT audience and app_id are bound together.
Organizations
Teams and memberships stay inside the same app boundary.
Common questions
FAQ
Do I need one auth deployment per product?
No. One 1Auth deployment can serve many products as long as every request is scoped to an app_id.
Can the same email exist in multiple apps?
Yes. The same email address can become separate users in separate apps by design.
Does 1Auth support shared identity or SSO between apps?
No. 1Auth is shared infrastructure with separate identity, not a cross-app SSO layer.
How should browser apps store access tokens?
Prefer in-memory access tokens plus refresh rotation. Avoid long-lived access tokens in persistent browser storage.
When things break
Troubleshooting
- If OAuth callbacks fail, compare the registered redirect URL byte-for-byte with what your frontend sends.
- If token validation fails, check issuer, audience, key rotation cache, and local clock drift.
- If a user sees expired-link errors, treat magic-link and reset tokens as single-use and issue a new link.
- If cross-app access succeeds, audit every place that reads tokens and confirm app_id plus audience enforcement.
Decision support
1Auth vs Auth0, Clerk, and Supabase Auth
The biggest difference is tenancy model. Auth0 and Clerk lean toward shared directories with organizations layered on top. Supabase Auth usually pushes full isolation into separate projects. 1Auth keeps one backend while isolating users at the database and token level.
| Capability | 1Auth | Typical hosted auth stack |
|---|---|---|
| Per-app user isolation | Native | Often indirect or split across tenants/projects |
| Per-app OAuth credentials | Native | Usually per connection or per instance |
| Self-hosted control | Yes | Frequently restricted or enterprise-only |
Background
About 1Auth
1Auth exists for teams running multiple independent products that should not share a global identity pool. It centralizes auth infrastructure without collapsing product boundaries.
Legal
Privacy policy summary
1Auth stores the minimum account and security data needed to authenticate users, rotate tokens, and retain audit events. Production deployments are responsible for their own data retention, provider configuration, and legal disclosures.
Legal
Terms summary
1Auth is open-source software. Usage terms depend on how you deploy, modify, and operate it inside your own infrastructure. Review the repository license and your own hosting obligations before offering it to end users.