Start from the clients, not the package name
Before choosing Sanctum or Passport, list who calls the API: first-party SPA, mobile apps, third-party partners, or all three. That answer picks the tool more reliably than blog benchmarks.
Sanctum is our default for first-party apps
For a Laravel backend + React SPA on known domains, Sanctum’s cookie-based SPA auth is simpler to operate. Personal access tokens work well for mobile when you do not need a full OAuth server.
Use Sanctum when:
- You control the frontends
- You want less moving parts in ops
- Token scopes can stay modest
Passport when you are an authorization server
Passport fits when external developers need OAuth2 flows, or you are issuing tokens as a platform. It is more surface area: clients, scopes, token lifetimes, and revocation UX.
Production failure modes we see
- CORS and
SameSitecookies misconfigured for SPA auth - Long-lived personal tokens committed to mobile apps without rotation plan
- Missing rate limits on
/loginand token endpoints - Forgetting to revoke tokens on password reset
Our recommendation pattern
Most Rayaxis client products start on Sanctum. We graduate to Passport (or a dedicated IdP) only when partner OAuth is a real requirement, not a hypothetical.
Ship the auth that matches the product boundary — then document token lifetimes for the team that inherits the repo.