- What is Laravel Passport used for?
- Laravel Passport is a first-party OAuth2 authorization server for Laravel applications. It issues and validates API tokens, manages OAuth clients and scopes, and supports grants such as client credentials, authorization code with PKCE, password, and device flow. Use it when your Laravel app needs to be the identity provider for APIs, partner integrations, SPAs, mobile apps, or machine-to-machine clients.
- How do I install Laravel Passport in a Laravel app?
- Install the package with Composer using composer require laravel/passport, then run php artisan passport:install. That command generates the RSA keypair, encryption keys, and personal access client, and it publishes the Passport migrations for OAuth clients, access tokens, refresh tokens, and related tables. You then wire the api guard to the passport driver and apply Passport middleware where needed.
- Does Laravel Passport support Laravel 12 and Laravel 13?
- Passport 12.x added Laravel 12 support on the 12.x line, while Passport 13.x targets a newer Laravel and PHP matrix. The version lines are not interchangeable, so you should pin Passport to the line that matches your application's Laravel and PHP versions. Check the changelog and support matrix before upgrading a production app.
- Which OAuth2 grants does Laravel Passport support?
- Passport supports client credentials for machine-to-machine APIs, authorization code with PKCE for third-party and first-party clients, password grant for legacy scenarios, refresh tokens, and device flow via RFC8628 in 13.x. The password grant is often considered legacy-hostile, so authorization code with PKCE is generally preferred for user-facing clients. Choose only the grants your application can actually justify.
- How do I protect API routes with Passport scopes and middleware?
- Passport integrates through the auth:api TokenGuard and HTTP middleware such as CheckClientCredentials, EnsureClientIsResourceOwner, and scope checks. Scope enforcement is opt-in, so you need to apply the appropriate middleware to every protected route or route group. A route-by-route inventory helps prove that no protected endpoint silently lacks scope enforcement.
- Where does Laravel Passport store access tokens and can I change the database connection?
- Passport stores opaque access tokens in relational database tables, so every authenticated request hits the token store. It assumes a relational database such as MySQL or PostgreSQL, and the database connection has been configurable since Passport 12.1. At scale, plan for the latency and database load that database-backed token validation can introduce.
- How should I manage Laravel Passport RSA keys in production?
- The oauth-private.key and oauth-public.key files must be stored securely and never committed to source control. Passport 13.x adds permission validation for these keys, but you should still keep them in a secrets manager, KMS, or HSM and define a rotation and recovery runbook. Losing the private key invalidates every token already issued by the application.
- What changed in Laravel Passport 13 and is upgrading from 12.x difficult?
- Passport 13 is a genuine migration rather than a patch bump. It changes behavior around hashed client secrets, UUID client IDs by default, deprecated JSON API support, renamed CheckClientCredentials middleware, reworked personal access token handling, and refactored migrations. It also makes refresh-token revocation optional, so review your revocation semantics carefully during the upgrade.
- How do I test Laravel Passport authenticated API endpoints?
- Use Laravel's testing helpers together with Passport's actingAs helper to authenticate a user and set scopes without running a full OAuth2 flow. Combine that with database refreshes so token tables and clients are reset between tests. Also test middleware coverage explicitly, because scope enforcement is opt-in and easy to miss.
- When should I use Laravel Passport instead of Sanctum or an external identity provider?
- Use Passport when your Laravel application should own the authorization server and you need real OAuth2 grants, client registration, scopes, and token lifecycle management. Sanctum is often a better fit for simple first-party SPA or mobile API tokens that do not require a full OAuth2 server. If identity already lives in Okta, Auth0, Entra ID, or Keycloak, Passport would create a redundant second source of truth and is usually the wrong tool.