Tokenable Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. This package sits in the gap between Laravel Sanctum (simple, token-based, no refresh rotation) and Laravel Passport (full OAuth2, heavy). If your roadmap includes mobile clients, SSR, and SPAs against one backend, this is a concrete reference implementation for what a middle-path "Sanctum-with-refresh-and-multi-model" layer looks like — useful as a spec even if you never install it.
• Multi-persona product architecture. "Multi-model" support (e.g., User, Admin, Customer, Device each holding their own tokens) maps directly to product decisions about whether to model distinct actor types as separate authenticatable entities or as roles on one. That choice ripples into permissions, admin surfaces, audit logs, and API contracts — worth deciding deliberately, not by default.
• Session and token lifetime policy. Refresh tokens imply a stance on access-token TTL, rotation-on-use, revocation on logout/password change, and "remember me" semantics across platforms. The package's support for refresh tokens is a forcing function to document that policy before engineering picks one ad hoc.
• Multi-surface roadmap sequencing. "APIs, SPAs, and SSR" with "multi-platform" suggests one auth system serving web sessions, mobile bearer tokens, and server-rendered flows. That supports a roadmap decision to consolidate auth rather than grow per-client bespoke solutions — a real maintenance cost driver.
• Security-surface scoping. Adopting (or copying) token issuance, hashing, expiry, and cleanup responsibilities makes explicit which team owns auth hardening, key rotation, and incident response.
• Not a decision it supports: production dependency selection. With 2 stars, 0 dependents, and a 0.01 score, this cannot anchor a buy decision for anything revenue-critical — it can only inform one.

When to Consider This Package

Consider it when:

• You are on a modern Laravel version and need token auth with refresh rotation across more than one authenticatable model — a combination Sanctum does not give you out of the box.
• You have one backend serving three or more client types (native app, SPA, SSR web) and want a single issuance/revocation path rather than three.
• You are prototyping or spiking an auth design and want a working implementation to react to, not a dependency to ship.
• You are willing to vendor or fork the code, read the source end to end, and own it — including adding tests, a security review, and an upgrade path. Treat it as a code sample with a permissive MIT license, not as a maintained library.
• Your team has Laravel-internals depth (guards, middleware, service providers, migrations) and can absorb maintenance.

Look elsewhere when:

• You need battle-tested, security-reviewed, widely deployed auth. Use Laravel Sanctum (first-party, SPA + API tokens, polymorphic tokenable already supports multiple models) and add a thin refresh-token layer yourself, or Laravel Passport if you genuinely need OAuth2/OIDC, scopes, and third-party clients.
• You require OAuth2/OIDC compliance, third-party delegation, or social login — Passport plus Socialite is the mature path.
• You have compliance, SLA, or vendor-risk requirements. A 2-star, single-maintainer, zero-dependent package has no disclosed vulnerability process, no release cadence guarantees, and no community to catch regressions.
• Your team is small and auth is not a differentiator — the total cost of ownership (audit + fork + maintain + re-audit on every Laravel upgrade) will exceed the cost of composing Sanctum with a refresh layer.
• You need ecosystem signals — docs, integrations, Stack Overflow coverage, hiring familiarity — to de-risk delivery.

Bottom line: evaluate as an input, not a dependency. The high opportunity signal here is real (multi-model + refresh + multi-platform is a genuine gap between Sanctum and Passport), but the adoption signal is near zero. The correct PM move is a timeboxed spike against your own requirements, then either compose Sanctum + a small refresh layer or fork the parts you need.

How to Pitch It (Stakeholders)

To executives: Authentication is table stakes infrastructure, and we currently have no documented policy for how tokens are issued, refreshed, or revoked across web, mobile, and server-rendered clients. A small open-source package (jundayw/tokenable, MIT) demonstrates the exact shape of the gap between Laravel's two official options — Sanctum is simple but has no refresh rotation, Passport is capable but heavyweight. It is not a candidate to ship as a dependency: two GitHub stars, no downstream users, one maintainer, no security disclosure process. My recommendation is a one-to-two week engineering spike using it as a reference to either (a) confirm Sanctum plus a small in-house refresh layer meets our needs, or (b) justify a scoped fork we own. This is a low-cost decision that prevents us from either over-building OAuth2 we don't need or under-building session security we can't retrofit.

To engineering: Read the source before anything else. Validate specifically: how tokens are generated and hashed at rest, refresh-token rotation and reuse detection, revocation on logout and credential change, expiry and cleanup scheduling, and how guards resolve across multiple models. Assume no tests, no CI, and no upgrade path — that is the budget you are pricing in. Deliverable from the spike is a written recommendation plus a threat-model note, not a merged dependency.

To security: Treat this as untrusted third-party code. No CVE history, no disclosed review, no maintainer track record. Any adoption requires a full read-through and our own test suite before it touches a production credential path — and even then, the fork cost likely exceeds composing first-party components.