Api Laravel Base Laravel Package

Product Decisions This Supports

• Build vs. buy for API auth plumbing. This package remains a candidate to eliminate custom token-issuance, middleware, and guard boilerplate on new Laravel API services — shifting effort from auth mechanics to differentiated product features. The 2.3.0 release doesn't change the build-vs-buy math, but it improves the odds that "buy" stays cheap over time.
• Time-to-market for new API surfaces. If it covers the standard flow (token issue → validate → refresh → revoke), it can compress the auth workstream on a new service from days to hours. This matters most on roadmap items gated behind backend enablement — and now also on items gated behind a Laravel 12 upgrade, since the package is ready for it.
• Standardization across services. Adopting one auth base gives a consistent contract for token lifetimes, error responses, and middleware behavior — a prerequisite for a shared API gateway, unified mobile clients, and cross-team observability.
• Security and compliance posture. Choosing between a maintained dependency and hand-rolled auth is a risk decision, not just a velocity one. The 2.3.0 release is a positive maintenance signal, but audit logging, token rotation, and credential storage are still things a PM should be able to point at rather than assume.
• Roadmap sequencing for identity features. Whether MFA, refresh-token rotation, social login, or multi-tenant scoping are in-house vs. inherited changes how much of next quarter's identity roadmap is "configure" versus "build."
• Framework upgrade risk (revised). The package now supports Laravel 12 and PHP 8.3 while holding backward compatibility with Laravel 9–11. This materially reduces the previously flagged "unproven package becomes an upgrade blocker" risk and supports a decision to keep it in the candidate pool through the next framework cycle.
• Vendor and maintenance exposure (partially de-risked). Community signal is still thin — no meaningful dependents or adoption data — but 2.3.0 demonstrates a maintainer tracking upstream framework releases. That shifts this from "likely abandoned" to "small but responsive maintainer": still a bus-factor item on the risk register, no longer a presumed blocker.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel API with conventional token-based auth and no need for full OAuth2/OIDC federation.
• Your stack is on, or moving to, Laravel 12 / PHP 8.3 — the package now explicitly supports it, so it won't be the thing holding back a framework upgrade.
• The team is small and Laravel-native, and the cost of an internal auth module genuinely competes with feature delivery.
• You want a thin, MIT-licensed base to fork or wrap behind an internal interface, rather than a heavyweight framework dependency.
• The auth surface you need is narrow and stable (login, token issuance, protected routes, logout) and unlikely to churn quarterly.
• You can pin the version, vendor the source, and own the tests internally — treating it as a starting scaffold rather than a long-lived upstream.

Look elsewhere when:

• You need enterprise SSO, OAuth2/OIDC, SAML, or SCIM — go to Laravel Passport, Sanctum plus a dedicated IdP, or a managed identity vendor instead.
• Compliance or procurement requires demonstrated maintenance history, published security disclosures, or a support contract; one responsive release is progress, but it is not the track record those reviews ask for.
• The product depends on long-lived auth stability across multiple teams — the bus factor still outweighs the boilerplate savings.
• You need guaranteed same-day support for the next Laravel major; 2.3.0 shows the maintainer follows framework releases, but with no release cadence guarantee, plan to absorb that work yourself.
• You already have a working internal auth layer — migration cost almost never clears the bar here.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel library that handles the standard mechanics of API authentication — the part every new service needs and no customer ever sees. The upside is speed: less custom security code, faster delivery on API-dependent roadmap items, and a consistent auth contract across services. Its latest release (2.3.0) adds Laravel 12 and PHP 8.3 support while keeping the older versions working, which tells us the maintainer is actively tracking the framework and that the library won't block our upgrade path. The caveat is unchanged: it still has no meaningful adoption or community traction, so we should treat it as a scaffold we evaluate and potentially own, not a dependency we outsource trust to. Recommendation: approve a short, time-boxed spike behind an internal auth interface, with a fallback to Laravel Sanctum/Passport if it doesn't hold up. Cost of the evaluation is low; the cost of adopting an unmaintained auth library as a default is not.

For engineering: It's a convenience layer over Laravel's guard/middleware stack for token-based API auth. Release 2.3.0 adds Laravel 12 and PHP 8.3 compatibility with illuminate/support and illuminate/http ^12.0, and holds backward compatibility back to Laravel 9 — no breaking changes or deprecations called out, so treat it as a drop-in version bump. That removes the framework-upgrade objection but not the ownership objection: we'd still wrap it in our own service interface, pin the version, vendor the source, and add integration tests around token lifecycle and failure modes. Evaluate against Sanctum as the baseline before committing.