Filament Passport Ui Laravel Package

Product Decisions This Supports

• Build vs. buy on internal OAuth admin tooling. Every team running Laravel Passport eventually needs a "who owns this client, what scopes does it have, who can revoke it" back office. This package is a credible buy (MIT, free) for that narrow slice, replacing a hand-rolled CRUD screen that typically costs 2–4 engineer-weeks to build plus ongoing maintenance.
• Compliance and audit readiness roadmap. If SOC 2, ISO 27001, or an enterprise security questionnaire is on the roadmap, "all OAuth configuration changes are logged via spatie/laravel-activitylog" is a concrete control you can point at. This is a checkbox you can close without custom work — but only for the admin actions surface, not for runtime authorization behavior.
• Operational burden reduction / self-service. The selfService() mode (added in 2.4.0) lets non-admin users manage only their own clients and tokens. That is a support-ticket reduction feature: integration owners stop filing "please rotate my client secret" requests against the platform team.
• Least-privilege policy enforcement at configuration time. Structured resource:action scope modeling plus the rule that user scopes must be a strict subset of client scopes gives you a defensible, reviewable answer to "why does this integration have write access?" It does not enforce anything at runtime — treat it as a governance control, not a security control.
• Prioritization signal on in-house platform work. If your backlog already contains "OAuth client management UI," evaluate this before committing sprint capacity. It also tells you what a mature internal OAuth admin surface looks like (grant-type-aware creation wizard, explicit token revocation, scope registry) — useful as a spec even if you don't adopt it.
• Not a fit for: products where OAuth authorization logic is the differentiator. The README is explicit that it does not implement flows, replace Passport, or enforce authorization at runtime.

When to Consider This Package

Adopt if all of these hold:

• You already run Filament v4 or v5 as your primary admin panel — the package assumes this; there is no headless or API-only mode.
• You already run Laravel Passport with more than one or two OAuth clients, or with multiple teams/integrations owning clients. Below that threshold the CLI is genuinely fine.
• You are on PHP 8.4/8.5, Laravel 12/13, and Passport 13. This is a hard gate — the requirements are pinned to the leading edge of the stack, which will exclude most production applications today.
• You need auditability of OAuth configuration changes and would otherwise build logging yourself.
• You are comfortable with a small, single-maintainer, low-adoption package for a security-adjacent admin surface.

Look elsewhere / build in-house if:

• You are not on Filament, or you use Sanctum rather than Passport. No partial-adoption path exists.
• Your stack is on PHP 8.2/8.3, Laravel 10/11, or Filament v3. The version floor is a blocker, not a preference.
• You need runtime enforcement of scopes, custom grant flows, or application-specific authorization rules. Out of scope by design.
• You require vendor support, SLA, or a security review you can hand to procurement. 11 stars, 0 dependents, one maintainer, MIT — the bus factor is the dominant risk.
• Your compliance posture forbids adding a low-maturity third-party package to the token-issuance administration path, regardless of the activity log.
• You need fine-grained RBAC on the admin UI beyond the binary admin/self-service split.

Diligence items before committing: the v2 architecture depends on a second package by the same author (laravel-passport-authorization-core) — check its health independently. The 2.4.0 changelog discloses a config-key bug where an option silently ignored the published config for multiple releases; that pattern argues for pinning versions and verifying configuration is actually taking effect. Also confirm the install command's migrations don't collide with your existing Passport tables.

How to Pitch It (Stakeholders)

For executives: We have a governance gap in our OAuth layer — API clients are created from the command line, nobody owns them, scope strings are ad hoc, and we cannot answer an auditor's question about who changed what. This package closes that gap by putting client, token, and scope management behind an admin UI with a full change log, at zero license cost. The tradeoff is a young, single-maintainer dependency in a security-adjacent area; we should treat adoption as a time-boxed pilot with a documented exit path rather than a permanent platform commitment.

For engineering: It's a Filament plugin that bolts resources onto Passport without touching Passport internals — clients by grant type, token inspection and revocation, and scopes modeled as resource:action pairs backed by a real schema. Clean-architecture use cases and domain events make the admin actions loggable and testable. Constraints are strict: PHP 8.4+, Laravel 12+, Passport 13, Filament 4/5, and it pulls in a companion core package. It does not do authorization enforcement — we still own that. Ask: does it fit the stack, and does the schema migration approach match how we manage Passport tables?

Recommendation: time-boxed spike (1–2 days) against a staging environment, gated on stack compatibility, with a written fallback to an in-house Filament resource if the dependency risk is judged too high.