smartins/passport-multiauth
Extends Laravel Passport to support multiple authenticatable models and guards, such as users and admins, in one app. Map OAuth clients to guards, issue and validate tokens per provider, and keep authentication flows isolated without separate Passport installations.
Architecture fit. The package patches Laravel Passport's token endpoint so a single OAuth2 server can issue tokens for multiple user providers/guards (e.g., customers, admins, partners) selected per request, instead of standing up one Passport installation per identity class. It fits a monolithic Laravel app with two to five distinct identity types sharing one codebase and one token store. It does not fit federated identity, per-tenant isolation, or cases where distinct identity classes need independent key sets or independent revocation domains.
Integration feasibility. Mechanically low-effort: composer require, publish config, register the service provider, define one guard + provider per user class in config/auth.php, then pass the provider on the token request. The package overrides Passport's AccessTokenController/token request path to resolve the provider dynamically. The real integration cost is not the package — it is the data model (which user table backs which provider), the guard/provider configuration, and verifying behavior for refresh, revoke, and scope endpoints. Assume a few hundred lines of app-side change and a non-trivial test matrix.
Technical risk. High, and concentrated in three places. First, staleness — and the new release sharpens rather than resolves this. v7.0.0 is a major version bump whose only change is "added support to Laravel 7.x," which confirms the package's compatibility ceiling sits at the Laravel 7 / Passport 7-era stack (consistent with the 2020-04-03 release date). Laravel 8+ and Passport 10+ remain unaddressed and should be treated as unsupported until proven otherwise; the version numbering appears to track Laravel majors, so a major bump here signals framework alignment, not API stability or renewed maintenance. Second, blast radius: this code sits in the token issuance path, so any defect is an authentication defect, and an unmaintained dependency there is a security-posture issue, not a convenience issue. Third, validation signal: 283 stars but zero recorded dependents is a weak proxy for production hardening — the package looks like a well-regarded utility rather than a battle-tested component. Treat it as a starting point to fork, not a dependency to adopt as-is.
Key questions. Which Passport major does the v7 line actually target, and is there any test matrix behind the Laravel 7.x claim? Does it extend Passport via public extension points or override internals (which determines fork cost on every Passport upgrade)? Does it correctly handle refresh tokens, token revocation, scopes, and per-provider client grants — or only the password/authorization-code issuance path? Is there a maintained fork or successor, and is any maintainer activity visible after the v7.0.0 release? Would a native design — multiple Passport clients on one issuer, distinct guards, or a custom UserRepository resolver — achieve the same outcome without a third-party dependency? What is the security patch posture if a CVE lands in this path?
Stack fit. Laravel 7.x is now the explicit, and effectively final, supported target; PHP 7.4–8.x era. If the application is on Laravel 8+ or a current Passport major, treat the package as incompatible without a fork — v7.0.0 does not close that gap. If the application is itself on Laravel 7.x, the package is a closer fit, but the app then carries its own upgrade debt alongside an unmaintained auth dependency.
Migration path.
packages/passport-multiauth under our namespace, add a test suite, and own it. Given the v7.0.0 signal, default to fork rather than adopt for any target above Laravel 7.x.Compatibility. Audit against auth.providers, Passport::tokensCan, route caching, config caching, and the CI matrix. Pin laravel/passport and laravel/framework to exact versions in composer.json and gate upgrades on the fork's tests. Verify behavior under php artisan route:cache and config:cache, which are common breakage points for packages that register routes dynamically. Establish early whether the fork must itself be forward-ported to a current Passport major — that decision, not the spike, is the dominant cost driver.
Sequencing. The fork-vs-adopt decision is now largely pre-made by the release: absent evidence of a maintained successor, plan to fork. Order: short spike (days, not a sprint) to confirm Passport alignment and extension points → fork and harden (one to two sprints, plus any forward-port to a current Passport major) → app integration behind a flag → security review → load and failure testing → GA. Do not sequence this in parallel with a Passport major upgrade.
Maintenance. This is effectively an ownership decision. Budget 0.1–0.2 FTE ongoing for dependency bumps, Passport major-release tracking, and security patches, spiking around Passport upgrades — and assume the full cost of forward-porting off the Laravel 7 baseline rather than waiting for upstream, which v7.0.0 indicates will not arrive. Without a named owner, the fork will silently rot and become a worse liability than the original package.
Support. No upstream support channel and no vendor to escalate to; v7.0.0 is a single narrow feature addition and does not evidence an active support commitment. Requires an internal runbook covering provider/guard configuration, key rotation, and token troubleshooting. Because failures are authentication failures, on-call must be able to diagnose guard/provider misconfiguration without reading the fork's source.
Scaling. The package does not change Passport's scaling profile: token issuance is stateless and cheap, and load is dominated by the token table, key cache, and any per-request guard resolution. Watch token table growth, key rotation, and Redis/cache availability as with any Passport deployment. No new scaling concerns are introduced.
Failure modes.
provider parameter silently falling back to the default guard, authenticating a user against the wrong provider.Ramp-up. Roughly one week for a Laravel-fluent engineer to learn Passport's token flow plus this package's deltas. Add another one to two weeks if the team owns the fork and must build and maintain the test suite — plus additional time if a Passport forward-port is required. Plan for at least two engineers to hold this knowledge — single-owner knowledge of an auth path is an operational risk in itself.
How can I help you explore Laravel packages today?