Filament Passport Laravel Package

Product Decisions This Supports

• Build vs. buy on OAuth admin tooling. If the product runs Laravel Passport behind a Filament panel, this package replaces two things a team would otherwise build: a CRUD surface for OAuth clients, access tokens, and authorization codes, and a set of Blade consent screens that Passport does not ship. For a PM, that is a sprint of internal tooling removed from the critical path of any API-access or third-party-integration initiative.
• Sequencing "API access" onto the roadmap without a UI tax. Because consent views are included, the feature can be scoped as auth capability first, OAuth UX polish later — branding, scope copy, and device-code entry can be refined in published views after the first release rather than blocking it.
• Whether token management is an internal ops surface or an end-user product surface. This is an admin/ops plugin, not a customer-facing developer portal. That distinction determines whether a self-service token UI (issue, rotate, scope, revoke by the customer) stays on the roadmap as separate work. Answer it explicitly before a stakeholder assumes "token management" ships to customers.
• Device-flow investment timing. Device Authorization (TV, CLI, kiosk, set-top scenarios) requires Laravel Passport v13. This makes a concrete roadmap fork: is the device grant a real customer need now (then fund the Passport 13 upgrade as a prerequisite), or is it speculative (then defer both the upgrade and the flow)?
• Incident response as a product requirement. Clients, tokens, and auth codes being visible and revocable in the panel turns "revoke the compromised client's tokens" from an engineering ticket into a UI action. For anything with an SLA or a security questionnaire, that is a supportability argument worth putting in writing.
• Standardizing the admin stack. If Filament is already the back-office convention, adopting a plugin that follows it keeps one admin surface instead of introducing a second, standalone OAuth dashboard to maintain and secure.
• Grant-profile scope decisions. The package enumerates the profiles it manages — authorization code (with optional PKCE), device authorization, password, implicit, client credentials — with confidential/redirect-URI/device constraints per profile. That table is a usable artifact for deciding which OAuth flows the product actually offers, and for killing ones nobody needs (implicit and password grants are rarely worth the review burden).
• Access-control design. The documented order — viewFilamentPassport gate, then a canAccess() callback, then open by default — forces a decision PMs should own: who inside the org can see and revoke customer credentials. Default-open is a product and compliance risk, not a config detail.

When to Consider This Package

Consider it when:

• The stack already matches exactly: Laravel with Passport 12.x or 13.x, Filament 4.x or 5.x, PHP 8.2+. This is a narrow plugin; there is no partial fit.
• The immediate need is admin visibility and revocation of clients, tokens, and auth codes, and building that in-house is not a good use of a sprint.
• Default consent and device-flow views are acceptable as a starting point, and the team is comfortable publishing and owning thin overrides rather than treating vendor views as immutable.
• Device flow is on the roadmap and the Passport 13 upgrade is acceptable.
• The organization can absorb early-stage dependency risk: pin the version, read the source, review the consent Blade views, and accept a fork as the fallback. MIT makes that practical.

Look elsewhere or build in-house when:

• The product uses Sanctum, a hosted identity provider (Auth0, Okta, Cognito), or a non-Filament admin stack. In those architectures the package does nothing for you.
• Device flow is needed but Passport 13 cannot be adopted this cycle.
• Procurement requires vendor support, an SLA, or adoption evidence. At 1 star and 0 dependents there is no ecosystem signal — evaluate the code, not the traction.
• The consent screen is brand-critical or compliance-sensitive (scope display, legal copy, audit logging of consent). Default views help, but customization and its maintenance are yours.
• Granular RBAC, multi-tenant isolation of token visibility, or audit trails beyond Filament policies are requirements. Verify rather than assume; multi-panel and tenancy behavior are unverified.
• The admin panel is still on Filament 3 — that disqualifies it outright.

Adoption gate: a timeboxed spike on a throwaway branch covering install, all supported grant flows end to end, and a token revocation exercise — plus a source read of the consent views and a check of the maintainer's release cadence and composer.json constraints. Escalate to a real dependency only if that passes.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed plugin that gives us an OAuth administration surface — client management, token revocation, and end-user consent screens — inside the admin panel we already run. It removes roughly a sprint of custom UI work, and it converts security response from "file a ticket and wait" into a click. The cost is zero and the license permits us to fork if the maintainer stops. The risk is maturity, not money: it is early-stage with no visible adoption, so the right move is a scoped pilot on an internal panel, not a broad rollout. We should approve the pilot and revisit once the consent flow and revocation path are verified in our environment.

For engineering (the summary to hand over): Drop-in Filament plugin layered over an existing Passport install — it registers resources directly against Passport's own models, adds no migrations, and is wired in with one ->plugins([FilamentPassportPlugin::make()]) line after Passport is installed and migrated. It covers clients, access tokens, and auth codes, and adds the authorization, device authorization, and device user code consent views that Passport does not provide. Config and views are publishable and individually overridable (a view can be set to a custom name or null to defer to something like Laravel MCP's own consent screen). Constraints to respect: PHP 8.2+, Filament 4/5, Passport 12/13; device flow needs Passport 13. Before we merge the dependency we need three things: a read of the published consent views to confirm they preserve Passport's state, PKCE, and redirect-validation semantics; confirmation that a gate or canAccess() callback is set so the panel is never default-open — this is a privilege-escalation surface; and a pinned version with the composer constraints checked, because a fork is our only fallback if it stalls.

Recommended next step: pilot on a low-blast-radius internal panel, gate access explicitly, publish and code-review the views rather than editing vendor files, and defer any decision about a customer-facing token portal until the internal surface has run for a release cycle.