- Is laravel/airlock the same package as laravel/sanctum?
- Yes. Airlock was renamed to Sanctum at v2.0.0, and the repository, README, badges, and changelog all resolve to laravel/sanctum. Treat laravel/airlock as a stale package identity and reference laravel/sanctum in composer.json, dependency records, and CI checks.
- How do I install Laravel Sanctum for API token authentication?
- Require laravel/sanctum with Composer, publish its config and migration, run the migration, add HasApiTokens to your User model, and configure the sanctum guard and middleware. In token mode, issue personal access tokens with the abilities and optional expiry your API needs. Do not install laravel/airlock for new work because that name is superseded.
- Which Sanctum version supports my Laravel version?
- Sanctum majors track Laravel majors: v3 targets Laravel 9 and 10, while v4 adds Laravel 11 support. Pin the Sanctum major to your framework major instead of using latest, and record both versions in your dependency register. Upgrading Laravel will usually force an auth-package major upgrade, so assign an owner for that step.
- How does Sanctum cookie-based SPA authentication work?
- Cookie mode uses Laravel's session guards, a CSRF cookie endpoint, and a configurable stateful domain allowlist rather than manual API tokens. Your SPA and API should share a top-level registrable domain or be explicitly listed as stateful. Cross-site deployments need extra CORS and cookie-policy attention because browser cookie rules can change.
- Can I use Sanctum token abilities for fine-grained permissions?
- Yes, each personal access token can be issued with abilities, and middleware or controllers can check those abilities before allowing an action. Be aware that abilities are coarse string checks, not a full scope or permission model. Sanctum also has no built-in token rotation or refresh-token primitive, so rotation must be implemented in application code.
- How do I test Sanctum authentication in Laravel feature tests?
- Use Sanctum::actingAs with the user and any abilities you want to simulate for token-guard tests. For real token flows, create a personal access token in the test and assert the protected endpoint accepts or rejects its abilities. Cookie and SPA tests should also cover session, CSRF, and stateful-domain configuration rather than only the happy path.
- What should I plan for Sanctum token expiry, revocation, and auditing?
- Token expiry is optional, so make a threat-model decision and, if expiry is mandatory, schedule the sanctum:prune-expired command and assign an owner. Tokens are stored hashed; revocation means deleting the token record, and you should document how tokens are identified in logs and audits. Token prefix and checksum support arrived in v3.2.6, which helps with safe identification.
- Should I use Sanctum or Laravel Passport for OAuth2?
- Sanctum is the right lightweight layer for first-party SPA cookie auth and simple API tokens. Passport or an external identity provider is the better fit if you need full OAuth2, OIDC, third-party delegated access, client-credentials flows, refresh tokens, or enterprise SSO. If any of those are on the 12-month roadmap, stop and re-scope before adopting Sanctum.
- How do I migrate from Passport or JWT to Sanctum?
- From native session or web auth, migration is additive: keep the web guard and add the sanctum guard for API and SPA routes. From Passport or JWT, existing token hashes cannot be ported, so plan a forced re-authentication window and issue new Sanctum tokens. Test the mixed-auth period carefully and document client cutover steps.
- Is laravel/airlock still maintained, and what are the alternatives?
- No. Airlock is superseded by Laravel Sanctum, the official first-party package for SPA and simple API authentication. Alternatives include Passport for OAuth2, an external IdP for SSO, or custom JWT, but Sanctum is usually the default for standard Laravel applications. Registry metrics understate its adoption because Sanctum ships in the Laravel skeleton and is consumed indirectly.