- How do I install and configure denniseilander/laravel-passport-scopes-restriction?
- Install it with composer require denniseilander/laravel-passport-scopes-restriction, publish the package config, register the middleware in your HTTP kernel or bootstrap, then declare which scopes each user or model is allowed to request. There are no database migrations or queue workers to run, so setup is mostly configuration. Budget most of your effort for validation across every grant type you use, not for installation.
- Which Laravel and Passport versions does this package support?
- Version 3.0.1 added Laravel 12 support, so Laravel 11 and 12 with Passport are the realistic targets, and PHP 8.2+ is a sensible baseline. Laravel 12 support alone does not guarantee your pinned Passport major is tested, so run composer why-not to confirm the constraint resolves against your locked Laravel and Passport versions. Check the CI matrix to see which Laravel and Passport pairs are actually exercised rather than merely allowed.
- Can I restrict which OAuth scopes a user can request in Laravel Passport?
- Yes. The package lets you assign allowed scopes per user or model and enforces them during token issuance, so a client cannot obtain a scope the underlying user or model is not permitted to request. That keeps scope policy in one place instead of scattering checks across controllers. It is a narrow extension to Passport and does nothing if you use Sanctum or an external identity provider.
- Does the scope restriction fail open or fail closed on unknown or misconfigured scopes?
- Confirm this explicitly before adopting: a security control must deny when a scope is unknown, unmapped, or misconfigured. Test a user or model with no scope map and a request containing an unmapped scope, and verify the token request is rejected rather than silently granted. Fail-open behavior is disqualifying for this kind of package.
- Does it cover every Passport grant type, including personal access tokens and client credentials?
- You must verify coverage for every grant type in your application: authorization code, password, client credentials, personal access tokens, and refresh. A grant the package does not intercept is a bypass path, and scope handling has shifted across Passport majors. Write one integration test per grant type that asserts both the allowed case and the denied case.
- How should I test that the scope restriction actually denies requests?
- Write integration tests that assert denial paths, not just happy paths. Cover a permitted scope, a forbidden scope, an unmapped scope, a user with no mapping, and each grant type you actually use. The package sits in the token-issuance path, so a regression is either privilege escalation or a production auth outage.
- How do I roll this out in production without breaking authentication?
- Run it in shadow mode first: let it evaluate and log denials without enforcing, compare those logs against your existing manual scope checks for a full traffic cycle, then flip to enforcing. Enumerate every grant type and client in use before that comparison, and spike the change in a scratch branch. That turns an auth-path change into a reviewable diff rather than a leap of faith.
- Is this a good alternative to Sanctum or to writing my own scope middleware?
- If you use Sanctum, Auth0, Keycloak, Cognito, or another identity provider, this package is irrelevant. If you already enforce scopes manually in middleware or controllers, the work is consolidation rather than migration, and running the package in parallel first is the safe path. Writing your own narrow scope check is also viable if you want to avoid another dependency in the token path.
- Is denniseilander/laravel-passport-scopes-restriction actively maintained?
- It is a single-maintainer project with a thin release cadence, so the bus factor is low. Version 3.0.1 is a maintenance patch: three of four changelog entries are Dependabot bumps to CI actions, and the substantive change is Laravel 12 support that widens a constraint rather than altering behavior. Confirm the MIT license, watch responsiveness on security reports, and be prepared to fork or vendor it if it goes stale.
- Is the scope configuration compatible with php artisan config:cache and normal deployments?
- The published config should merge cleanly with your config-cache pipeline and per-environment overrides; verify with php artisan config:cache in a staging deploy before production. A scope map that does not survive config caching, or that requires a rebuild to change, is a deployment hazard. Test the deploy path, not just the local development path.