Sanctum Laravel Package

Product Decisions This Supports

• Auth architecture for the next client surface. Sanctum covers both patterns we are likely to need in the same release: cookie/session auth for our first-party SPA (stateful domains + CSRF) and bearer tokens for mobile apps, CLIs, and third-party integrations. That lets us ship a mobile or partner API without standing up a second authentication system or re-litigating the login flow.
• Build vs. buy on token issuance. Token generation, hashing, storage, lookup, revocation, expiration, and a sanctum:prune-expired command already exist and are maintained by the Laravel core team. The realistic build alternative is 2–4 engineer-weeks plus permanent security ownership. This is a clear "buy" (at zero license cost), and the decision is cheap to reverse because tokens live in one table we control.
• API permission model and pricing tiers. Token abilities (string scopes) plus the CheckAbilities / CheckForAnyAbility middleware let us decide scope granularity once — read-only vs. write vs. admin — and enforce it at the route level. This is the mechanism behind "which tier gets which API access," so it should be settled in the API design doc, not discovered during implementation.
• Device and session management as a product feature. Tokens are per-device and individually revocable, which unlocks "log out of all devices," "revoke this integration," and customer-facing key management screens. These are support-cost reducers and, for security questionnaires, an expected capability rather than a nice-to-have.
• Customer-facing API key program. We can issue scoped, expiring keys to customers without building an OAuth consent flow. last_used_at (now opt-in as of 4.3.0) gives customers and support activity visibility; the token-validated event feeds audit logging.
• Security/compliance roadmap inputs. Token expiration plus scheduled pruning sets a defensible baseline for credential hygiene, which is usually the first question on a vendor security review. Note the tradeoff: no native refresh-token rotation, so "short-lived credentials" is not something we can promise on this package alone.
• Scale-readiness checkpoint. 4.2.0 added indexes to personal_access_tokens, and last_used_at write amplification is now configurable. That is a pre-launch decision for high-volume APIs, not a post-launch incident.
• Multi-audience separation. Multiple provider support means separate token issuers for consumers, partners, and internal services, useful if we ever need to revoke an entire class of access at once.

When to Consider This Package

Adopt when:

• The backend is Laravel (8–13) and will stay Laravel for the planning horizon.
• We control the clients: our own SPA, our own mobile app, plus a modest set of partner integrations.
• We need authentication and revocation quickly and do not need delegated third-party authorization.
• The team is Laravel-fluent and comfortable owning a migration, a config file, and a scheduled prune job.
• Procurement and license review should be trivial — MIT, first-party, no vendor relationship.

Look elsewhere when:

• We need to be an OAuth2 authorization server — third-party apps acting on behalf of users with a consent screen. That is Laravel Passport, not Sanctum.
• We need short-lived access tokens with refresh-token rotation, or token-binding guarantees (mTLS, DPoP).
• Enterprise SSO/SAML or an external IdP is a contractual requirement.
• Social login is in scope (that is Socialite; Sanctum is the session layer underneath, not the provider).
• Authorization needs depth beyond string scopes — roles, per-resource policies, hierarchical permissions. Sanctum answers "who is this," not "what may they touch."
• The platform is going polyglot: the guard, middleware, and token model are Laravel-specific and do not travel to a Go or Node service layer.

Data caveat: the reported "0 dependents" is a metadata artifact, not an adoption signal. Judge this package on its first-party status, changelog cadence (through 4.3.x, with Laravel 13 and PHP 8.5 support), and its position as the Laravel default. It is well-maintained and low-risk, but it is deliberately minimal — that minimalism is the feature, and also the ceiling.

How to Pitch It (Stakeholders)

For executives: Sanctum is the Laravel core team's own authentication package, MIT-licensed, with no vendor contract, no per-seat cost, and no procurement cycle. Adopting it is the lowest-risk way to unblock our SPA, mobile, and partner-API roadmap: it removes an estimated multi-week build, and the maintenance burden sits with the framework maintainers rather than with us. The exit cost is low — tokens live in a table we own — so this is a reversible decision, not a platform commitment.

For engineering: One migration, one trait on the user model, one guard in config, and a scheduled sanctum:prune-expired. Cookie-based auth for the first-party SPA via stateful domains; bearer tokens for everything else. Scope enforcement is route middleware; testing uses actingAs. Two things to settle before we start: (1) our ability/scope naming scheme, since it becomes a public contract with API consumers, and (2) whether last_used_at tracking is on, given its write cost at volume. Known gaps to design around rather than discover: no refresh-token rotation, and no authorization server — if either becomes a requirement, the migration path is Passport or an external IdP, and we should say so in the architecture doc now rather than later.