- What does smartins/passport-multiauth do?
- It extends Laravel Passport so a single OAuth2 server can issue and validate tokens for multiple user providers or guards, such as customers, admins, and partners, instead of running a separate Passport installation per identity class. It patches Passport's token endpoint to resolve the provider dynamically per request. It fits a monolithic Laravel app with roughly two to five identity types sharing one codebase and one token store, but it is not designed for federated identity or per-tenant isolation.
- How do I install passport-multiauth in a Laravel application?
- Install it with Composer, publish its configuration, and register the service provider. Then define one guard and one provider per user class in config/auth.php and pass the provider on the token request. The mechanical setup is low effort, but the real integration cost is the data model behind each provider and building a test matrix for issue, refresh, revoke, and scope behavior.
- Which Laravel and Passport versions does passport-multiauth support?
- The last release was on 2020-04-03, in the PHP 7.4 to 8.x era, so it targets older Passport majors. Compatibility with Passport 10+ and Laravel 9+ cannot be assumed and must be proven with a spike against your exact pinned versions. If your app is already on a current Passport major, treat the package as incompatible until testing shows otherwise.
- How do I configure multiple guards and providers for Laravel Passport multi-auth?
- Define a guard and a provider for each user class in config/auth.php, with each provider mapping to its user model and table. The package then uses the provider passed on the token request to resolve the correct identity class. You should also audit the setup against auth.providers, Passport::tokensCan, route caching, and config caching.
- Does passport-multiauth handle refresh tokens, revocation, and scopes correctly?
- The package overrides Passport's AccessTokenController and token request path to resolve the provider dynamically, so token issuance is the primary covered path. Refresh tokens, revocation, scopes, and per-provider client grants must be verified for each provider in your own test matrix. Do not assume full coverage until you have tested those endpoints explicitly.
- Is smartins/passport-multiauth still maintained and safe for production?
- The package has not had a release since April 2020, while Laravel and Passport have moved through several major versions. Because the code sits directly in the token issuance path, any defect becomes an authentication defect, making the lack of maintenance a security-posture concern rather than a convenience issue. It also has 283 stars but zero recorded dependents, which is a weak signal for production hardening.
- What are alternatives to passport-multiauth for multi-guard API authentication in Laravel?
- You can often achieve the same outcome with multiple Passport clients on one issuer, distinct guards, or a custom UserRepository resolver that selects the provider. If identity classes need independent key sets or independent revocation domains, separate Passport installations may be the cleaner design. Evaluate a native approach before adopting a third-party dependency in the auth path.
- How do I request a token for a specific provider with Passport multi-auth?
- You pass the provider on the token request, and the package resolves it dynamically through the guard and provider configuration in config/auth.php. Each provider must map to the correct user model and table before the request is made. Test issuance for every provider you support, since a misconfigured provider fails at authentication time.
- Will passport-multiauth break route:cache or config:cache in Laravel?
- Packages that register routes dynamically are common breakage points under route:cache and config:cache. Because this package overrides Passport's token controller and request path, you should verify behavior under both commands in CI. Include those checks in your compatibility spike rather than discovering the issue in production.
- Should I fork passport-multiauth instead of requiring it through Composer?
- Given the stale release history and its position in the authentication path, treat the package as a starting point to fork rather than a dependency to adopt as-is. Decide fork versus adopt before writing integration code, because integrating upstream and then forking doubles the work. If upstream is incompatible, vendor-fork it under your namespace, add a test suite, pin exact Laravel and Passport versions, and put the new token endpoint behind a feature flag until parity is demonstrated.