Identity & Auth Providers
User identity, SSO, OAuth/OIDC - Auth0, Keycloak, Clerk, WorkOS, Okta. Don't build your own auth.
Identity & Auth Providers
User authentication is a problem you should almost never solve from scratch in 2026. Modern identity providers handle passwords, MFA, SSO, OAuth/OIDC, SAML, social login, magic links, passkeys — all behind an API your app calls.
This is distinct from Secret Management (machine-to-machine credentials, dynamic secrets) — identity is about end users and their organizations.
What an Identity Provider (IdP) Gives You
| Without one | With one |
|---|---|
| Build & secure your own password storage | Hosted, audited, breach-checked |
| Build MFA from scratch (TOTP / SMS / WebAuthn) | One toggle |
| Implement OAuth flows from RFCs | SDK call |
| Handle "Sign in with Google / Apple / GitHub" | Configured in their dashboard |
| Build SAML for enterprise sales | Provider handles it; you charge for SSO |
| Custom password reset flows | Built-in |
| Comply with SOC 2 / GDPR / HIPAA | Inherit their compliance |
| User impersonation for support | First-class feature |
The compounding value: once you've integrated an IdP, adding "Sign in with X" is config, not code.
The Players
| Provider | Notes |
|---|---|
| Auth0 (Okta) | The pioneer; full-featured; expensive; great DX |
| Clerk | Newer, developer-first; pre-built UI components; React/Next.js focus |
| WorkOS | "Enterprise features for B2B SaaS" — SSO, SCIM, audit logs as products |
| Okta | Enterprise IAM; deep workforce features; expensive |
| Keycloak | Open-source, self-host; Red Hat-backed |
| Authentik | Open-source, self-host; modern alternative to Keycloak |
| Stytch | Passwordless-first; passkeys, magic links, OTP |
| Supabase Auth / Firebase Auth | Bundled with their BaaS; great if you're already there |
| AWS Cognito / Azure AD B2C / GCP Identity Platform | Cloud-managed; deep integration with cloud IAM |
| Ory | Open-source toolkit (Kratos, Hydra, Keto) — most flexible, most assembly required |
| Logto | Open-source, modern, B2C and B2B |
The space is crowded. Strong defaults in 2026:
- B2C consumer app — Clerk (fast to ship, pretty UI) or Auth0 (proven, more flexible)
- B2B SaaS that needs SSO — WorkOS (purpose-built for "enterprise checklist") or Auth0
- Self-host — Keycloak (mature) or Authentik (modern)
- Already on Supabase / Firebase — their bundled auth
Two Different Problems
| B2C | B2B | |
|---|---|---|
| Who logs in | Individual users | Users within organizations |
| Account model | Flat: one user, one identity | Hierarchical: org → users → roles |
| Auth methods | Social, magic link, passkeys, passwords | SSO (Google Workspace, Okta), SAML, OIDC |
| Onboarding | Self-serve | IT-driven; SCIM for user lifecycle |
| Pricing | Per-MAU | Per-org, often with SSO upcharge |
| Common providers | Clerk, Auth0, Stytch, Firebase | WorkOS, Auth0, Okta |
A B2B product that doesn't support SAML / SCIM cannot sell to enterprises. WorkOS exists specifically to ship that checklist quickly.
OAuth / OIDC: The Vocabulary
The standards every IdP speaks. Worth knowing the terms before you implement:
| Term | What it is |
|---|---|
| OAuth 2.0 | Authorization framework — "this app can act on behalf of this user" |
| OIDC | Identity layer on top of OAuth — adds "this is who the user is" |
| Authorization Code flow | User logs in at the IdP; your app gets a code; exchanges for tokens. The standard flow. |
| Implicit flow | Legacy; tokens in URL. Don't use. |
| PKCE | Protects Authorization Code from interception; mandatory for SPAs/mobile |
| Client Credentials flow | Machine-to-machine; no user involved |
| Refresh token | Long-lived; exchanged for new access tokens |
| Access token | Short-lived; used to call APIs |
| ID token | JWT proving who the user is (OIDC) |
| Scope | What the app is allowed to do (read:profile, write:orders) |
| JWT | Self-contained signed token; verified offline |
| Opaque token | Random string; verified via introspection endpoint |
If you're hand-rolling OAuth, you're almost certainly making a mistake. Use your IdP's SDK.
Learning Path
1. Getting Started
Integrate Auth0 (or Clerk) into a Node app - signup, login, sessions, protected routes
2. Patterns
SSO, SCIM, RBAC, multi-tenant, passkeys, social login, refresh-token rotation, impersonation
3. Best Practices
Token handling, session security, migration, lock-in, observability, compliance
When to Self-Host
Hosted IdPs are the right default. Self-host when:
- Data-residency compliance forbids your data leaving a region a hosted provider doesn't cover.
- Pricing at scale makes the math not work (~$10K-100K+ MAU territory).
- You need deep customization no hosted provider supports.
- Air-gapped or government-regulated environments.
Keycloak and Authentik are the open-source standards. Both are real systems with real ops — you need someone owning them.
When NOT to Use an IdP
Honest cases:
- A static site with no users — no auth needed.
- An internal tool used by a handful of engineers — your VPN + ssh is fine.
- A demo / prototype — bare passwords in a
.envand move on.
For anything user-facing in production: use an IdP. Rolling your own is a multi-year tax of CVEs, edge cases, and missed compliance.
The classic mistake is "we'll add SSO later." Late SSO migration is painful — you rebuild your user model around organizations, redo every signup flow, and rewrite every "lookup user by email" query. If you might ever sell to enterprises, model orgs from day one — even before you wire up SSO.