Sanctum Tokens Laravel Package

Technical Evaluation

Architecture fit. This is a Nova resource tool, not a service, middleware, or token-issuing layer. It renders a panel inside a Nova resource detail page and calls Sanctum's existing personalAccessTokens relation to list, create, and revoke tokens. That means the architectural decision is really a stack decision: it is only viable where Laravel + Sanctum + a licensed, already-deployed Nova panel exist. It adds zero new infrastructure, zero new persistence, and no new endpoint surface beyond the Nova API routes the tool registers. If Nova is not already in the stack, this package is not a reason to adopt Nova — a TPM should treat that as an automatic disqualifier rather than a scope expansion.

Integration feasibility. The install path is short and well understood: composer require, HasApiTokens on the tokenable model, Sanctum migrations run, SanctumTokens::make() placed in a resource's fields() (not NovaServiceProvider::tools()), then php artisan nova:publish. The dominant failure mode is misplacement — putting it in tools() or a dashboard renders nothing, silently. The second is a missing trait or migration, which surfaces as an empty panel or a query error rather than a friendly message. Both are configuration errors a competent Laravel engineer resolves in an hour; neither is a package defect. That keeps the feasibility risk low and the estimation confidence high.

Technical risk. Three risks matter at the TPM level:

• Authorization is unowned by the package. It ships no token policy. Anyone with update on the parent resource can mint or revoke that model's API credentials — effectively "become this user via API." This is a security decision the team must make explicitly, not a default the package provides. Mitigation is a field-level gate plus a dedicated manageApiTokens policy method.
• One-time plaintext reveal. Only the hash is stored. If the operator dismisses the modal before copying, the only remedy is revoke-and-recreate. This is predictable, high-volume support friction and should be designed around (copy affordance, warning copy, runbook) rather than discovered.
• Maintenance signal is weak. 56 stars, zero dependents, single maintainer, last release March 2024. That release predates Nova 5 and is a CSS-only patch. Treat this as vendorable code: pin the version, read the token-creation path before exposing it broadly, and hold a fallback estimate for a small custom Nova resource so the team is never blocked.

Secondary but worth logging: Sanctum's last_used_at is lazily and throttled-updated, so stale-token reporting built on it will be misleading; the panel has no "expires at" column by default even though expiration still applies per config/sanctum.php; and ['*'] is a wildcard in Sanctum's ability check, so any "all abilities" option is a privilege-escalation click if styled carelessly.

Key questions to resolve before committing:

1. Is Nova already licensed and deployed, and which major version? (Nova 5 compatibility is untested against this tag.)
2. Which model(s) own tokens — User, Admin, Team? Each tokenable model needs its own resource and its own tool instance; cross-model views require custom code.
3. Who is allowed to issue and revoke tokens, and does the parent resource's update policy already imply that? If not, we need a policy change, not a package change.
4. Do we need audit trail, rotation policy, or compliance-grade controls? If yes, this package is one input to that design, not the design.
5. Is there a named owner who will accept vendoring/patching responsibility if upstream goes quiet?

Integration Approach

Stack fit. The package sits cleanly on an existing Laravel/Nova/Sanctum stack and requires no changes to application architecture. It assumes laravel/nova and laravel/sanctum are present and that the target model already uses HasApiTokens. Ability lists should be constrained via the tool's fluent API rather than left as free text, and the same list mirrored into the OpenAPI spec — otherwise issuing and enforcement drift within a quarter.

Migration path. There is nothing to migrate. No data model changes, no schema additions, no backfill. Existing tokens created through the API or console appear in the panel immediately because it reads the same personal_access_tokens table. The only "migration" is organizational: moving token revocation out of ad-hoc DB queries and engineering tickets into a support-facing UI, which is a process change that should be announced, not assumed.

Compatibility. Pin ^2.1.1. Verify the service provider FQCN against vendor/jeffbeltran/sanctum-tokens/src/ before relying on vendor:publish for config or views — the docs are thin and the surface is small. Nova 5 should be validated on a branch with laravel/nova pinned as the rollback; if the panel looks wrong (spacing, borders, typography), confirm the version is >=2.1.1 and that nova:publish / asset rebuild ran after both install and upgrade before concluding incompatibility. Customizations should be done by subclassing the tool in-app and overriding views — not by forking — and any overridden view must be re-checked against the Nova-aligned styles or it will drift.

Sequencing. A defensible order of work:

1. Scope and policy first. Decide which resource(s) get the panel, who can see it, and add the field-level gate and manageApiTokens policy. Doing this after launch means a window where resource-editors can mint credentials.
2. Pre-flight the stack. Confirm Nova version, Sanctum installed, trait present, migrations run. This is cheap and eliminates the majority of "it doesn't work" outcomes.
3. Install on one resource, one environment. Staging first, nova:publish, and verify create → copy → use → revoke end to end with a real API client.
4. Constrain abilities and normalize naming. Ship the ability list and, if needed, a name convention (e.g. <user-id>-<environment>) so last_used_at triage across many rows is tractable.
5. Add audit at the model, not the tool. Hook PersonalAccessToken::deleted() so revocations from the Nova UI and from the API both land in one log. This is the single highest-leverage integration step for security operations.
6. Add bulk operations as Nova Actions. "Revoke all for this user," "rotate for the tenant" belong in Actions that delete from personal_access_tokens with logging — mixing bulk modes into the panel confuses operators.
7. Write the runbook and enable support. One-time-reveal warning, revocation steps, escalation path.

Operational Impact

Maintenance. Low code surface, low change rate, but low upstream activity. Budget a small recurring allowance: an annual compatibility check against Nova and Sanctum majors, plus a vendored-fork contingency if the maintainer stops shipping. The realistic steady state is "pinned, working, untouched for a year" — which is fine, provided someone owns the pin. Assign that owner explicitly; unowned pins become emergencies during framework upgrades.

Support. The package reduces a real class of tickets ("please revoke my API key," "which tokens are active") and moves them from engineering to support/security. In exchange it creates a new, predictable ticket type: the lost plaintext token. Every occurrence is revoke-and-recreate, roughly two minutes of operator time. Volume is bounded by how often tokens are issued, not by how many users exist. Set expectations in the section heading ("tokens expire per Sanctum config; plaintext shown once") so the UI itself absorbs part of the support load.

Scaling. Scaling dimensions are narrow. Token count per model is small in practice; the panel paginates as Nova does. The real scaling limits are organizational: per-model scoping means User and Admin each need their own resource and tool instance, and team- or tenant-scoped tokens need the tool attached to that tokenable resource instead. Cross-model administration ("show me every token in the tenant") is out of scope and should be a custom report or query, not a stretched use of this tool. Treat it as an ops console for one model at a time.

Failure modes and their signatures.

• Empty panel → missing HasApiTokens or missing migration. Check both before touching the package.
• Nothing renders at all → tool placed in tools() or a dashboard instead of fields().
• Styling broken after upgrade → asset rebuild not run; re-run nova:publish.
• Silent over-permissioning → no policy gate; the highest-consequence failure because it looks like success. This is why the authorization work is sequenced first.
• Stale-token dashboards that cry wolf → last_used_at laziness misread as "never used."
• Plaintext token lost → not a failure of the package, but the dominant operational defect from the user's perspective.

Ramp-up. An engineer familiar with Laravel and Nova is productive in under a day; the install and first token are ~30 minutes, with the remainder spent on policy and view customization. Support staff need a short runbook — create, copy immediately, revoke, escalate — not training on Sanctum internals. The asymmetry is worth naming to stakeholders: engineering ramp-up is trivial, but the governance ramp-up (who may mint credentials, how revocations are audited) is the actual work and should be scoped as such rather than folded into "install a package."