Filament Sanctum Laravel Package

Technical Evaluation

Architecture fit. This package is a presentation-layer plugin, not an authentication component. It registers via SanctumPlugin::make() in a Filament panel provider and reuses Sanctum's native personal_access_tokens table — no parallel guard, no second token format, no proprietary migration. That containment is the central fact for a TPM: the blast radius of a failure is the admin panel's token screen, not the API itself. Remove the package tomorrow and issued tokens keep working; only the in-panel affordance to mint and revoke them disappears. The package also draws the right seam between capability and policy — it renders the management UI and delegates "who may see this" to a configurable Laravel gate (authorization.enabled + authorization.gate). That is the correct division of responsibility and is what makes it governable rather than something that quietly widens your attack surface.

Integration feasibility. Standard Laravel/Filament choreography: composer require devtical/filament-sanctum laravel/sanctum, publish Sanctum's provider and migrate (only if Sanctum is not already live), add HasApiTokens to the User model, register the plugin, optionally publish config/translations, then define the gate. Realistic effort: 2–4 hours when Sanctum is already installed and a gate/policy convention exists; 1–2 dev days when the ticket also carries standing up Sanctum, agreeing the authorization model, validating multi-panel or multi-tenant behavior, and socializing the fact that all historical tokens become visible in the panel on day one. The build comparison is unfavorable: a bespoke screen means form + abilities picker + one-time token reveal + revoke action + tests + i18n, roughly 10–20 dev hours, plus permanent ownership. Buy-over-build is the clear call here.

Technical risk. Ranked for a decision memo:

• Authorization misconfiguration — highest severity; the only risk that becomes a security incident. The package does not decide token visibility or scoping for you. If the gate is left disabled and the page is reachable by ordinary panel users, or if the resource is not scoped to the authenticated user/tenant, one user can see and revoke another's tokens. Note the asymmetry that makes this serious: revocation is immediate, destructive, and unrecoverable, because Sanctum persists only a hash after creation. Gate and scope must be configured and verified before the page is enabled in production, not retrofitted.
• Adoption and bus-factor signal — medium. 54 stars, zero dependents, effectively one maintainer (Kristories) with occasional drive-by contributors. Mitigating factors: MIT license, genuinely small code surface, and a fork-or-absorb contingency measured in 1–2 dev days rather than a rewrite. Absorbable risk, but it must be a recorded, conscious acceptance with an owner.
• Version-matrix churn — medium. Documentation is internally inconsistent: the changelog claims Filament 5 / Laravel 13 support at v1.1.0 and Filament 3/4 + Sanctum v4 at v1.0.0, while the README still describes the older flow. Pre-1.0 pins will not work on a Filament 4/5 panel. Pin an exact version and commit the tested combination (Filament × Laravel × Sanctum) to the repo so upgrades are reproducible.
• Documentation thinness — low. Install, config, and gate wiring are covered adequately; unstated are the listing's default scoping per user, exact navigation-permission semantics, and how "last used" is derived. Onboarding cost is "read the resource class," which is small at this size.
• Historical token exposure — low probability, high surprise. Because the plugin reads the existing table, every token ever issued appears in the panel on day one, revocable by anyone who can reach the page. Usually desirable, but it must be a deliberate decision with the security owner rather than a post-launch discovery.

Key questions. (1) Which panel(s) get the plugin, and is access gated — if so, by which gate and who owns the gate's definition and test? (2) Is the token listing scoped to the authenticated user, and does that hold under impersonation or tenant switching? (3) Are we comfortable exposing all pre-existing tokens to panel operators, or do we need a cutoff/backfill conversation first? (4) Do we define abilities as a fixed enum in config, or do we need them to vary per role — and if per-role, is the config file the right home? (5) What is our acceptable maintenance posture for a single-maintainer dependency: pin, vendor, or absorb on a trigger? (6) Does the panel's audit/logging requirement cover token creation and revocation, or must we observe those events ourselves?

Integration Approach

Stack fit. The package only imposes obligations where Sanctum is absent. If the API tier already runs Sanctum, the surface area is one panel plugin registration plus a config file; the only model change is the HasApiTokens trait, which a Sanctum-fronted API usually already has. If Sanctum is not yet deployed, this ticket quietly inherits the full Sanctum rollout — provider publication, migrations, CORS/domain configuration, and whatever token-issuance flows exist outside the panel. A TPM should split those into separate work items so the panel plugin is not carrying an unrelated platform migration on its back.

Migration path. Effectively a greenfield add-on with no data migration of its own. The two things worth pre-empting: (a) the plugin is additive, so rollback is composer remove plus a config revert — plan the reversal before the rollout, not after; and (b) the "historical tokens appear immediately" behavior is not a migration step but behaves like one, so announce it to whoever owns the security review and to any support staff fielding user questions about unfamiliar tokens in their list.

Compatibility. Support is a matrix, not a boolean, and the docs are behind the code. Confirm the exact tested combination before committing: Filament 3/4 + Sanctum v4 at v1.0.0, Filament 5 + Laravel 13 at v1.1.0. Pin a specific release in composer.json, record the matrix in the repo README or an ADR, and add a CI job that exercises the panel's own test suite against the pinned versions so a Filament minor bump surfaces as a build failure rather than as a broken admin page. Treat Filament minor releases as needing a verification pass, since the changelog shows real breakage from Filament internals (MenuItem → Action, TagsColumn → TextColumn) across major versions.

Sequencing. Five stages, each independently shippable:

1. Decide authorization first. Gate name, definition, and the per-user/tenant scoping expectation. This is the gate to production; everything else is cosmetic by comparison.
2. Pin and pilot. Install on a non-production panel or staging branch with an exact version pin; verify token creation, one-time token display (confirmed as the only moment the plaintext exists), revoke, and the /admin/admin/sanctum URL-resolution fix.
3. Config and i18n. Choose navigation placement (user menu vs. sidebar), abilities list shape (columns, list), expiration defaults and presets (allow_expiration, default_expiration_days, expiration_presets), and publish translations if EN/ID coverage is insufficient.
4. Security review and rollout. Walk the reviewer through the gate, the scoping, and the historical-token exposure; then enable for an internal cohort before opening to all panel users.
5. Operationalize. Add a smoke test asserting the gate denies and the page 403s for unauthorized users; document the escalation path to the maintainer and the fork trigger.

Operational Impact

Maintenance. Low in absolute terms but non-zero and concentrated in one place: version-drift between Filament and this plugin. The package has a real changelog and release cadence (0.0.1 → 1.1.0 with meaningful fixes shipped, including a duplicate-path URL bug and a column-rendering bug found in production use), which is reassuring; but the dependency chain is Filament → plugin → your panel, and the plugin's release timing is not on your schedule. Budget a small recurring line item — a few hours per Filament upgrade cycle — and assign a named owner. Keep a documented "absorb it" path: at this code size, forking the resource class into the app is a 1–2 day task, which makes the whole dependency bounded rather than open-ended.

Support. First-line support lands on the panel's own admins and then on whoever owns the API tier, because the questions users ask ("what is this token?", "why did my integration stop working?") are Sanctum questions wearing a Filament UI. Prepare a short runbook: what tokens are, that revocation is immediate and irreversible, that the plaintext is shown exactly once at creation, and how to escalate a suspected token compromise (revoke, rotate, audit). The plugin's contributor email in the security section is a single human — do not design an incident process that depends on their response time.

Scaling. The mechanics scale fine: token creation and revocation are rare, single-row operations against an indexed table, and the listing paginates through Filament's table primitives. The real scaling concern is organizational, not technical — token count per user and ability granularity grow with the number of integrations. If the abilities list is a config-file enum, it stays legible; if every team wants its own scopes, the config becomes a coordination bottleneck and you should plan for the list to be governed by a code-owning team rather than edited ad hoc. Multi-panel and multi-tenant deployments need explicit verification: confirm the resource scopes to the current tenant/panel user, because that behavior is exactly what the docs leave implicit.

Failure modes. Worth naming explicitly, each with a mitigation:

• Over-permissive gate → cross-user token compromise. Highest impact. Mitigate with a denial test in CI and a pre-launch security sign-off; treat "gate disabled in config" as a production-blocking condition.
• Accidental or malicious revocation by an over-scoped operator → silent integration outage. Because Sanctum stores only a hash, there is no recovery and no "undo." Mitigate with tight gate membership, an audit trail on the revoke action, and a support script that tells affected users to reissue.
• Filament upgrade breaks the plugin's UI → panel page errors. Mitigate with a version pin and a panel smoke test in CI.
• Package abandonment → no upstream fixes. Mitigate with the fork contingency and by keeping the plugin's usage confined to one panel provider registration so removal is a single-line change.
• Historical token exposure surprise at go-live. Mitigate by making it an explicit, signed-off decision during sequencing stage 4.
• Expiration defaults mis-set (e.g., allow_expiration off) → long-lived tokens with no policy enforcement. Mitigate by aligning default_expiration_days and expiration_presets with the API tier's documented token policy before rollout, not after the first audit.

Ramp-up. Fast for anyone fluent in Filament: install is copy-paste from the README, and the config file is small and self-describing. The genuine learning isn't the package — it's the Sanctum mental model (hashed storage, one-time plaintext reveal, ability scopes, last-used semantics) and the panel's authorization convention. Plan half a day of reading plus a staging walkthrough for the implementing engineer, and a 15-minute briefing for panel admins on what changed and what revocation means. Do not skip the briefing: the first time a non-technical operator revokes a production integration's token, you will want them to have already known that there is no undo.