Prompt
What auth stack should I use for web and mobile apps?
Latest observation
Oct 6, 2026
OpenAI APIWeb search: off
The “best” auth stack depends mostly on whether you want to build auth yourself or outsource it, and how much control you need over web/mobile flows.
My default recommendation
For most teams building both web + mobile:
Option A — Fastest to ship / least maintenance
- Auth provider: Auth0 or Clerk
- Web: their hosted/SDK-based auth
- Mobile: native SDK + PKCE/OAuth redirect flow
- API backend: verify JWTs at the edge/backend
This is usually the best choice if you want:
- social logins
- email/password and magic links
- SSO / enterprise later
- passkeys eventually
- minimal security burden
Pick:
- Clerk if you want a very developer-friendly product-led experience and modern UI components
- Auth0 if you need more enterprise/advanced identity features and flexibility
Option B — Best for control + lower vendor lock-in
- Auth protocol: OAuth 2.1 + OpenID Connect
- Web: use NextAuth/Auth.js (if Next.js) or a thin OIDC client
- Mobile: use AppAuth (native OAuth/OIDC libraries)
- Backend: validate JWTs using your issuer’s JWKS
- Session storage: httpOnly cookies on web; secure token storage on mobile
This is a good choice if you:
- have an engineering team comfortable with auth
- want more control over UX and architecture
- may switch identity providers later
Option C — If you want to own everything
- Identity: self-hosted Keycloak
- Web/mobile: OIDC clients
- Backend: JWT validation against Keycloak issuer
Good if you need:
- strong control
- enterprise SSO
- self-hosting / compliance
- custom identity flows
But it’s more operationally heavy.
Practical stack I’d use today
If you’re building a modern product
- Web app: Next.js
- Auth: Clerk or Auth0
- Mobile: React Native or Flutter with OIDC-compatible login
- Backend: Node/Go/Python API validating JWT access tokens
- Database user profile: separate app user table keyed by auth provider
sub
Session model
- Web: use httpOnly, secure cookies for session
- Mobile: use PKCE + refresh tokens stored in secure storage (Keychain/Keystore)
- API: stateless JWT access tokens, short-lived
- Refresh: rotate refresh tokens
This is the safest common pattern.
What not to do
- Don’t roll your own password auth unless you must
- Don’t store tokens in localStorage for web if you can avoid it
- Don’t use the same auth flow for web and mobile without considering the platform
- Don’t put long-lived bearer tokens in a place accessible to JS if you can use cookies instead
Short version by scenario
- Startup / MVP: Clerk
- Enterprise / advanced IAM: Auth0
- Need self-hosting: Keycloak
- Need custom / low-level control: OIDC + AppAuth + Auth.js/NextAuth
- Firebase-based product: Firebase Auth can work, especially if you’re already in Firebase/Google Cloud
My personal default
If you want one recommendation without more context:
Use Clerk for web + mobile if you want speed and a good DX.
Use Auth0 if you expect enterprise requirements.
Use OIDC/JWT behind the scenes, with httpOnly cookies on web and secure token storage on mobile.
If you tell me:
- your framework (Next.js, React Native, Flutter, etc.),
- whether you need SSO/enterprise,
- whether you want hosted vs self-hosted,
…I can recommend a specific stack and architecture.