Product Decisions This Supports
- Build vs. buy on API authentication. If the product already runs on Voyager (Laravel admin/BREAD), this package answers "how do we let a mobile app or SPA talk to the same backend?" for roughly the cost of an install, instead of a 1–2 sprint auth build. That is the whole decision it informs: spend engineering weeks on token issuance, refresh, role-aware login, and route guards, or inherit a thin community layer.
- Channel expansion sequencing. It makes "ship a companion mobile app / decouple the frontend from Blade" a feasible near-term roadmap item rather than a quarter-long auth program — if the admin surface is already Voyager.
- MVP and internal-tool scoping. For prototypes, back-office tooling, hackathon builds, or a first API for an existing admin, the out-of-the-box login/register/token endpoints absorb the undifferentiated plumbing so scope stays on the differentiating product surface.
- Risk-adjusted roadmap weighting. With 8 stars, 0 dependents, a single-maintainer release history, and a last release in Feb 2024, treat this as vendorable source, not a dependency you inherit passively. The decision it actually drives is "time-box a spike, abstract the auth boundary, and pre-commit to an exit path."
- Not a decision it supports: public-facing, high-assurance API auth. Do not let this package's availability justify deferring SSO, MFA, refresh-token rotation, or audit-grade session controls.
When to Consider This Package
Adopt when:
- Voyager is already the admin backbone and you want to reuse its users/roles/permissions rather than stand up a parallel identity store.
- The consumer is internal or first-party (internal tools, an early mobile client, a partner pilot) where a security review is proportionate to blast radius.
- Speed dominates: the auth surface is blocking a demo, a pilot, or a validation milestone.
- Your team is comfortable pinning the version, reading the source, vendoring a fork, and owning patches — because that is what you are signing up for.
Look elsewhere when:
- Greenfield Laravel. Use first-party Sanctum (SPA/mobile tokens) or Passport (full OAuth2). They carry the framework's maintenance, LTS alignment, and the hiring pool's familiarity. Taking an 8-star dependency over a first-party option is a hard trade to defend.
- You need anything beyond basic token auth — social login, MFA/2FA, SSO/SAML, password policy, email verification flows, per-device revocation, refresh rotation, rate limiting, or abuse detection. This module will not carry that load.
- Your procurement or security posture requires vendor/support guarantees, SBOM provenance, or an actively maintained dependency with a contributor bench. One maintainer and zero dependents is a continuity risk you must be able to absorb.
- Voyager isn't in the stack. Retrofitting Voyager to get this package is inverted logic; you would be buying an admin panel for an auth helper.
How to Pitch It (Stakeholders)
To executives: We can open a mobile/API channel without a dedicated auth build. This module bolts token-based REST authentication onto the admin backend we already run, so the incremental cost is an install and a short validation spike rather than a multi-week engineering workstream. License is MIT, so there is no commercial spend. The trade is maintenance exposure: it is a small, single-maintainer community package with limited adoption, so we propose a time-boxed proof (one sprint or less), wrapping the auth layer behind our own interface, and budgeting a documented migration to Laravel Sanctum if the channel proves out. Net: low cost, fast validation, contained downside.
To engineering: Treat this as a scaffold, not a foundation. Pin the version, read the token issuance and route-guard code before it touches a real user, verify token expiry/revocation semantics and role enforcement against Voyager's ACL, and isolate it behind an internal auth adapter so a swap to Sanctum is a contained change. Do not extend it toward MFA, SSO, or social login — those are out of scope by design.
Recommendation: Conditional go — approve a bounded spike only if Voyager is already load-bearing and the first API consumer is internal or first-party; otherwise standardize on Sanctum/Passport and spend the difference once rather than twice.