Sanctum Tokens Laravel Package

Product Decisions This Supports

• Build vs. buy for internal token administration. If your stack already runs Laravel Sanctum and Laravel Nova, this package replaces a small custom Nova resource for creating, listing, and revoking personal access tokens. Frame the decision honestly: the build is small but non-zero (field UI, one-time plaintext reveal, authorization gating), so this is a tactical shortcut worth roughly a fraction of a sprint — not a platform bet.

• Support and security operations capacity. Enables support/security staff to answer "revoke this API key," "which tokens are active for this user," and "clean up stale credentials" without database access or an engineering escalation. The measurable win is reduced ticket latency and faster containment during a token-exposure incident.

• Roadmap triage. Classify this as internal admin/ops tooling, not customer-facing differentiation. Prioritize only if token management is a current support or security pain point; deprioritize if Nova isn't already in the stack — installing Nova to use this package is a category error.

• Security hygiene initiative scoping. Supports revocation workflows and visibility into active Sanctum tokens, but does not deliver token rotation policy, compliance-grade audit trails, or SSO-gated credential administration. If those are on the roadmap, budget them as separate workstreams and don't let this package's adoption create the false impression they're covered.

• Multi-model API access design. The tool attaches to any Nova resource whose model uses Sanctum's HasApiTokens trait, which forces a useful product question: do tokens belong to User, Admin, Team, or a tenant model? Answer that before rollout, because per-model scoping means cross-model or tenant-wide views require custom code.

• Authorization model decision. The package ships no token policy — anyone who can edit the parent resource can mint or revoke that model's credentials. That's effectively "become this user via API." Adoption requires an explicit decision on a dedicated manageApiTokens policy and field-level conditional rendering; treat this as a product/security requirement, not an implementation detail.

When to Consider This Package

• Consider it when you already run Laravel Nova and Laravel Sanctum, need a lightweight admin panel for personal access tokens, and want to skip building a custom Nova resource for basic list/create/revoke.

• Consider it when the primary need is per-token management on a resource detail page — an admin opens a user record and creates or revokes that user's token. Pair bulk revocation or tenant-wide rotation with Nova Actions instead of expecting this tool to cover them.

• Consider it when your team can vendor, fork, or replace it. With 56 stars, zero dependents, a single maintainer, and a last release in March 2024, treat it as small vendorable code, not critical infrastructure.

• Look elsewhere when you're not on Nova, are planning a Nova 5 upgrade without capacity to test compatibility (the latest tag predates Nova 5 and is a CSS-only patch), or require actively maintained vendor-supported credential management.

• Look elsewhere when you need advanced audit logging, rotation policy, multi-tenant token administration across models, or SSO-gated admin workflows. This is a thin Nova UI over Sanctum, not a governance layer.

• Look elsewhere when authorization can't be tightly controlled. If resource update permissions are broad or informally granted, adding a token panel widens the blast radius; fix the policy model first.

How to Pitch It (Stakeholders)

• For executives: This is a low-cost internal admin add-on for teams already on Laravel Nova and Sanctum. It lets support and security staff revoke API tokens faster with less engineering involvement, improving incident response and cutting manual database work. It is not customer-facing and doesn't change the product experience. Because adoption and maintenance signals are weak (small user base, single maintainer, no release since March 2024), approve it as tactical tooling with a fallback plan — likely a small custom Nova resource — rather than a long-term platform dependency. Expect roughly a fraction of a sprint saved versus building the screen ourselves; the real decision is whether Nova is already paid for and deployed.

• For engineering: It fits an existing Nova + Sanctum stack and can replace a small custom token-management screen. Non-negotiables before shipping: verify Nova version compatibility and pin ^2.1.1; place the tool in the resource's fields() (not NovaServiceProvider::tools() — it silently renders nothing there); confirm HasApiTokens and the personal_access_tokens migration; run php artisan nova:publish after install and after every upgrade. Review authorization explicitly, since token administration is credential administration. Warn admins that the plaintext token is displayed exactly once (hash-only at rest — revoke-and-recreate is the only remedy), constrain abilities to an enumerated list rather than free text, avoid a casually clickable ['*'] wildcard, and account for Sanctum's lazy last_used_at before building stale-token reporting. Keep a fallback estimate for a custom Nova resource so the team is never blocked.

• For support and security leads: This gives a simple UI to inspect and revoke Sanctum tokens tied to a user or other tokenable model. It reduces "please revoke my API key" tickets and speeds containment when a token is exposed. Be clear about the boundaries: it does not replace audit logging, rotation policy, or broader credential governance — and the panel has no expiration column by default, so expiration behavior lives in Sanctum config, not in the UI.