jundayw/tokenable
jundayw/tokenable is a Laravel package that adds token support to Eloquent models, helping you generate and manage tokens for authentication or access control. A lightweight helper for token-based APIs and PHP applications.
Architecture fit. jundayw/tokenable is a Laravel package (service provider + trait + middleware pattern) that targets a gap Sanctum and Passport leave open: token issuance that is polymorphic across multiple authenticatable models and scoped across multiple client platforms (API, SPA, SSR), with refresh-token lifecycle included. The conceptual architecture is a reasonable fit for Laravel's existing conventions — HasTokens-style trait on models, a migration for a polymorphic tokenable table, guard/middleware registration, and a config file for TTLs and platform definitions. For a product that needs first-class multi-tenant or multi-persona auth (e.g., admins, customers, and service accounts on one backend, each with separate SPA and SSR sessions), that is a genuinely useful primitive and aligns with how Laravel teams already compose auth.
Integration feasibility. Mechanically low-friction: composer require, publish config and migrations, add the trait to each authenticatable model, register the guard, and wire middleware onto route groups. There is no separate identity server, no external dependency, and no vendor lock-in beyond the package itself. The effort is measured in hours for a spike, not weeks.
Technical risk. This is where the evaluation turns cautious. The package has 2 stars, 0 dependents, and a composite score of 0.01 against an opportunity score of 8.32 — a strong signal that the problem is real and underserved while the implementation has effectively no production validation. Token authentication is security-critical surface area, and refresh-token flows in particular are where subtle defects become incidents: refresh-token replay, rotation without reuse detection, tokens stored in plaintext rather than hashed, missing revocation on password change, timing-unsafe comparison, and overly broad token scopes. A single-maintainer package with near-zero community scrutiny cannot be assumed to have addressed these. Treat the code as unreviewed until a security pass confirms hashing at rest, rotation and reuse detection semantics, revocation hooks, and per-platform scoping enforcement.
Key questions.
auth config?Stack fit. Best suited to a Laravel monolith or modular monolith where auth is in-process and the team already owns the user model. It is a poor fit for organizations standardized on an external IdP (Auth0, Cognito, Keycloak) or on Passport's full OAuth2 grant model, since adopting a second token system creates split-brain auth. It is a credible fit as a replacement for Sanctum in apps that have outgrown Sanctum's single-model, no-refresh assumptions but do not want OAuth2 complexity.
Migration path. Do not rip out the existing guard. Sequence it as: (1) install alongside Sanctum, publish migrations, add the trait, and stand up the new guard on a non-critical route group; (2) dual-issue during a transition window — legacy tokens still validated by the old guard, new sessions minted by tokenable; (3) backfill or force re-authentication at token expiry rather than migrating token rows, since hashed token formats will not be portable; (4) decommission the old guard only after the new path has run clean through at least one full refresh cycle. Where possible, mirror the existing token table schema so reporting and revocation tooling keep working.
Compatibility. Verify against the actual target matrix before committing: Laravel major versions in use, PHP minor, database (MySQL/Postgres for polymorphic index behavior), and any middleware that inspects Auth::guard(). The highest-risk incompatibility is guard name collisions and anything that assumes personal_access_tokens exists. Also confirm the package plays with whatever SPA/SSR session strategy is in place (cookie vs bearer) — mixing them is where SSR flows usually break.
Sequencing. Weeks 1–2: spike on a branch, read the source end-to-end, run a security review of token generation, storage, comparison, rotation, and revocation. Weeks 3–4: integrate on one low-risk surface (internal admin API or a single SSR app) behind a feature flag. Weeks 5–8: expand to customer-facing API and SPA, instrument issuance/refresh/revocation metrics. Only after a clean cycle consider it a default. Decision gate: if the security review surfaces unresolved findings and the maintainer is unresponsive, the correct outcome is to fork the package internally or implement the token table in-house — the surface area is small enough that a fork is a realistic fallback, and that fallback should be priced in from day one.
Maintenance. The dominant operational fact is bus factor: one maintainer, no dependents, no ecosystem pressure to keep it current. Laravel majors ship annually and auth internals churn; a package at this adoption level is unlikely to be promptly patched for a Laravel upgrade or a CVE. Budget for owning a vendored fork or a patch layer. Version-pin aggressively and treat every upgrade as a deliberate re-review rather than a routine composer update.
Support. Effectively none beyond reading the source. There is no community to lean on for edge cases, no Stack Overflow corpus, and no third-party security advisories. Internal documentation and a named owner are mandatory, not optional. The team adopting it should be prepared to answer its own questions by reading the code.
Scaling. Two dimensions. Data: a polymorphic token table grows with every login and every refresh, so index on (tokenable_type, tokenable_id) and on the token lookup column, and schedule pruning of expired and revoked rows — unbounded growth is the most likely slow-burn failure. Traffic: token validation is a per-request DB read unless cached; at high request volume, add a short-TTL cache keyed by token hash with explicit invalidation on revoke, or expect the auth table to become a hot spot. Refresh-token churn multiplies write volume relative to a no-refresh design.
Failure modes. (1) Security: token or refresh-token leakage, replay of a rotated refresh token, failure to revoke on password reset or account disable — highest severity, lowest detectability. (2) Correctness: platform scoping not enforced server-side, letting an SPA token reach SSR-only endpoints. (3) Availability: auth table saturation or missing indexes degrading every authenticated request at once. (4) Upgrade: a Laravel bump breaking the package and blocking framework upgrades across the whole app. (5) Schema: polymorphic FK handling differing between MySQL and Postgres, leaving orphaned tokens after model deletion.
Ramp-up. Low for a mid-level Laravel engineer to use — the trait-and-middleware pattern is familiar, a day to first working token. High to own safely — expect one to two weeks of senior engineer time for a genuine security read, plus ongoing ownership of the fork. The honest framing for stakeholders: the opportunity score of 8.32 says the capability gap is real and worth solving; the 0.01 score says this specific package is a starting point or a reference implementation, not a dependency to adopt on trust. Recommend a time-boxed spike with a hard security gate, and pre-approve the fork path so the team is not blocked if the gate fails.
How can I help you explore Laravel packages today?