- How do I set up multi-guard authentication with Laravel Passport using this package?
- Install the package with Composer, publish its config file, and define a separate guard and provider for each identity table in config/auth.php, for example admins and customers. Then register the package's custom grant types in your AuthServiceProvider boot method so each guard can issue and validate its own OAuth2 tokens. Optionally apply the supplied trait to your identity models. The wiring is simple; the real work is verifying that each grant binds a request to the intended provider and client.
- Does hamedov/passport-multiauth let admins and customers have separate tokens?
- Yes, that is the core purpose of the package. It adds multi-guard support to Passport so separate user models and providers each issue and validate tokens through distinct guards, working around the limitation that Passport's password grant resolves only a single user provider. Only adopt it if you genuinely have separate identity tables. Role separation on one users table is better handled with Passport scopes or Sanctum.
- Which Laravel and Passport versions does passport-multiauth support?
- There is no published compatibility matrix in the context provided, so check composer.json on the repository before assuming a version works. The package subclasses League OAuth2 Server grant types and Passport bridge internals, which are outside Laravel's backwards-compatibility promise. Passport 11 and 12 changed client model handling, route registration and hashing behavior, so expect breakage on each major. Pin Laravel and Passport to exact minor versions and treat every bump as a regression-test event.
- Is passport-multiauth actively maintained and safe for production?
- Adoption is negligible: no dependents, no integration examples in the wild, and very little social proof. The code sits directly on the credential-validation and token-issuance path, so a provider-resolution bug means cross-tenant token issuance or privilege escalation rather than a cosmetic defect. Auth-critical code with almost no user base has had no adversarial review. The safest stance is to treat it as a reference implementation, fork it internally, and complete your own security review before any production traffic.
- What is the difference between passport-multiauth and Laravel Sanctum?
- Sanctum is first-party authentication for SPAs and mobile apps using sessions or simple API tokens, and it is officially supported and actively maintained. This package targets OAuth2 semantics with multiple distinct identity providers behind Passport. If you only need role separation or first-party auth, Sanctum or Passport token abilities on a single users table is the correct, lower-risk answer. Multi-provider OAuth2 is a much narrower need than most multiauth requests actually require.
- Can a client for one guard request a token for another provider?
- That is exactly the abuse case you must test before trusting the package. Because providers are resolved per guard, a bug in that resolution could let an admin client obtain a merchant token or allow refresh-token provider drift. The package ships no tests or examples covering this scenario. Run deliberate cross-provider tests with mismatched client and provider pairing, and write a threat model before production use.
- How do I test multi-provider token issuance and prevent privilege escalation?
- Build integration tests covering every grant multiplied by every provider, asserting that a token issued for one guard cannot authenticate against another guard's protected routes. Include refresh-token flows, revoked clients, and mismatched client and provider combinations. Because the package has no existing test suite to lean on, this coverage is entirely your responsibility. Treat any failing cross-provider assertion as a release blocker.
- Should I install passport-multiauth from Packagist or fork it?
- Do not consume it directly from Packagist on the auth path. Fork it into an internal namespace, pin it, and add tests plus a security review of the grant logic. The code volume is small enough that owning a vendored, tested fork, or writing a provider-aware PasswordGrant subclass yourself in roughly 100 to 200 lines, is lower total risk than depending on an unmaintained package. Only adopt as a dependency if you can fund ongoing maintenance.
- How do I register the custom grants in AuthServiceProvider?
- After publishing the config, open app/Providers/AuthServiceProvider.php and add the package's grant classes inside the boot method using the registration calls documented by the package. You also need matching guards and providers defined in config/auth.php so each grant can resolve the correct identity store. Because the README excerpt here is empty, confirm the exact method signatures against the repository source for your specific Passport version. Wire it up on a throwaway branch first and verify each grant end to end.
- Are there maintained alternatives to passport-multiauth?
- There is no obvious actively maintained drop-in alternative identified in this evaluation, and the package itself has no dependents or ecosystem pressure to keep it current. The cheapest safe path is often in-house: a small provider-aware subclass of Passport's PasswordGrant, or a custom grant that resolves the provider from the guard. That keeps you as close as possible to supported Passport APIs and puts the security review under your control. Budget one sprint for a spike that issues and refreshes tokens for two providers and attempts deliberate cross-provider abuse.