Filament Sanctum Laravel Package

Product Decisions This Supports

• Build vs. buy for API token self-service. Teams shipping a public or partner-facing API on Laravel Sanctum inevitably get the same request: "how do I get a key?" A bespoke admin screen costs roughly 10–20 dev hours plus permanent maintenance (abilities picker, one-time token reveal, revocation flow, i18n, tests). This package compresses that to a 2–4 hour install when Sanctum is already live. That is a straightforward buy decision, and the saved sprint capacity is the headline.
• Unblocking API onboarding without a roadmap slot. If API access is a committed capability but token issuance is still a manual, ops-assisted process, this is a stopgap that ships this sprint rather than waiting for the platform team's backlog. It converts a support burden (engineers minting tokens by hand in tinker) into a self-service surface.
• Feature-scoping decisions around API tiers. The abilities configuration with multi-column layout is where product actually lives: the list of scopes you expose here is your API's permission model, surfaced to the customer. Defining posts:read vs. posts:write becomes a product conversation with a concrete artifact, not an abstract security doc.
• Expiration and lifecycle policy as a product default. Preset durations (7/30/60/90 days) let you ship a defensible security posture without building policy UI. This is a decision you can make and enforce in a config file — good for compliance conversations, good for reducing stale-credential risk.
• Delegated admin without delegated engineering. The gate-based authorization means you can hand token management to a support lead or customer-success admin via an existing Laravel gate, rather than granting panel-wide access or building a role. That's a real operational lever for scaling support.
• Roadmap de-risking on the "API dashboard" epic. If a customer-facing developer portal is on the roadmap but unfunded, this buys time and generates real usage data — which tokens get created, which abilities get chosen, how often revocation happens — that will inform the eventual portal's design.

Decisions this does not support: multi-tenant token isolation guarantees, customer-facing (non-admin) token portals, or any API-adjacent capability beyond credential lifecycle.

When to Consider This Package

Adopt when all of these hold:

• You are on Filament 3, 4, or 5 (verify the exact tested combination — the version matrix is inconsistent across README and changelog; pin precisely and record it).
• Laravel Sanctum is already installed and in production use, or is a committed near-term dependency. If you're not on Sanctum, the cost of adoption is really the cost of adopting Sanctum — evaluate that separately.
• Token management is currently manual or absent, and the alternative is a bespoke screen competing for roadmap time.
• You have a clear answer to "who should see this page" — an existing gate, policy, or role convention you can wire in. If you don't, the correct first ticket is defining that authorization model, not installing the package.
• You are comfortable with a single-maintainer, 54-star, zero-dependent package in the admin panel. The mitigation is that the blast radius is genuinely contained: it's a UI layer over Sanctum's native table, introduces no parallel auth path, no custom guard, no own migrations. If it's abandoned, API auth keeps working; you fork or absorb it in 1–2 dev days.

Look elsewhere or build when:

• You need per-tenant or multi-panel scoping guarantees the package doesn't decide for you. It renders the surface; it does not own the scoping policy. If your product is multi-tenant, verify the resource scopes to the authenticated user before enabling — one user seeing and revoking another's tokens is a security incident, and revocation is unrecoverable since Sanctum stores only a hash.
• You need a customer-facing token UI (outside the admin panel), self-service registration, or a developer portal. This is an internal-admin affordance.
• You need token usage analytics, rate-limit management, rotation workflows, or audit trails beyond what Sanctum records. "Last used" is the ceiling here.
• Your security owner requires maintained dependencies with a support commitment. Zero dependents and one maintainer is absorbable risk, but it must be consciously accepted and written down, not discovered later.
• You're pre-1.0 on Filament and unwilling to pin an exact version — the version-support story across releases is genuinely confusing.

Non-negotiable pre-launch checklist: scoping verified per-user/per-tenant, gate enabled and tested, and a deliberate conversation with the security owner about the fact that every historically issued token becomes visible and revocable on day one. That last one is usually desirable — but it should be a decision, not a surprise.

How to Pitch It (Stakeholders)

For executives — one paragraph: We can give customers self-service API token management inside our existing admin panel for roughly half a day of engineering, instead of 2–3 weeks building and indefinitely maintaining a custom screen. It's a UI layer over the Sanctum token system we already run — it adds no new authentication path and no new data. If we ever remove it, API authentication continues working unchanged. The decision to make is a small, bounded bet that unblocks API onboarding now and buys us real usage data before we commit to a proper developer portal. The associated risk is a low-adoption open-source dependency, mitigated by a permissive license and a codebase small enough to absorb in-house if needed.

For engineering — the ask: Register the plugin, add HasApiTokens to the User model, publish the config, and define the authorization gate. Two to four hours if Sanctum is already live. Two explicit conditions before it ships: (1) verify the resource scopes tokens to the authenticated user — this is the one failure mode that becomes a security incident, and revocation can't be undone; (2) pin an exact version and record the tested Filament/Laravel/Sanctum combination in the repo, because the published version-support matrix is inconsistent. Everything else — navigation placement, abilities list, expiration presets — is config, not code.

For security — the framing: Token creation, visibility, and revocation all move from engineer-mediated to gate-mediated. Access is restricted by a standard Laravel gate, so it inherits whatever policy model you already trust. Two things need your sign-off: the ability/scope list we expose to users, and the acknowledgment that pre-existing tokens appear in the panel on day one and are revocable by anyone with page access. Expiration presets let us enforce a maximum credential lifetime by default, which is a net improvement over today's hand-minted, never-expiring tokens.