- What is joy/voyager-api-auth used for?
- It is a satellite module for Joy Voyager that adds REST API authentication endpoints such as login, logout, token refresh, and user profile. It lets a Laravel app expose a headless Voyager backend to SPA or mobile clients using the same user, role, and permission model as the admin panel. It is not a standalone authentication library and assumes you already run Joy Voyager.
- Does joy/voyager-api-auth work without Joy Voyager?
- No. The module is tightly coupled to Joy Voyager, a maintained fork or extension of the Voyager Laravel admin panel. Its main value is bridging Voyager's admin-centric permissions to API clients, so it fits poorly if you are on stock Voyager or no Voyager at all. In that case, treat the repository as a reference implementation rather than a dependency.
- How do I install and configure joy/voyager-api-auth in Laravel?
- Mechanically it is a Composer require plus service provider registration, published config, and routes under an API prefix. The real installation question is whether its version constraints intersect with your Laravel major, PHP version, and Joy Voyager major. Check composer.json before committing, because the package pins against multiple moving majors.
- Which Laravel versions does joy/voyager-api-auth support?
- The provided context does not confirm exact Laravel version support, including Laravel 11 or 12. The package pins against both a Laravel major and a Joy Voyager major, and those pins move independently. Inspect composer.json for laravel/framework, php, and the parent Joy Voyager constraint before planning adoption.
- Does joy/voyager-api-auth use Passport or JWT?
- The overview says the module adds REST API auth endpoints with Passport support, while the blurb describes JWT-backed tokens for login, logout, refresh, and profile. That distinction matters because Passport, Sanctum, and custom JWT implementations have different security and maintenance profiles. Verify the actual token mechanism in the source and composer dependencies before committing.
- How are Voyager BREAD permissions enforced on API routes?
- The module is meant to reuse Voyager's user, role, and BREAD-derived permission model for API access. However, the provided context does not specify whether a single middleware enforces permissions or whether checks are per-controller. This is a security-critical question to resolve by reading the route definitions, middleware, and permission checks.
- Is joy/voyager-api-auth production-ready and actively maintained?
- Treat it as high risk: it has roughly 8 stars, 0 dependents, and a single maintainer, so it is effectively unvalidated in production by anyone you can point to. There is no evidence in the context of a security disclosure policy, external audit, or test coverage and CI you can read as a spec. A 2024 release suggests the maintainer is alive, but one release is not a maintenance track record.
- Does it include rate limiting, token revocation, and refresh token rotation?
- The provided context does not confirm whether rate limiting, token revocation, refresh rotation, or credential-stuffing protections ship out of the box. Authentication is a security-critical path, so you inherit liability for token issuance, TTL, revocation, and permission mapping correctness. Verify these controls in the code or plan to implement them yourself.
- Can I use joy/voyager-api-auth for a SPA or mobile app?
- Conceptually yes, if you are already on Joy Voyager: it exposes login, logout, refresh, and profile routes for headless clients. For lower risk, place an internal AuthService interface in front of every endpoint so application code does not call the package directly. That preserves the option to swap to a first-party Sanctum implementation later without touching callers.
- What are alternatives to joy/voyager-api-auth?
- The main alternative is a first-party Laravel Sanctum implementation, using this repository's routes, middleware, and permission checks as a reference spec of roughly 300 to 500 lines. If you are committed to Joy Voyager, adopt-and-wrap the package behind your own interface or vendor-fork it and take ownership of CI, tests, and patch cadence. If you are not on Joy Voyager, do not add this as a dependency.