Filament Passport Ui Laravel Package

Technical Evaluation

Architecture fit. The package is a UI/governance layer only — it explicitly does not implement OAuth flows, replace Passport, or enforce authorization at runtime. That scoping is honest and correct, and it makes the package unusually low-blast-radius for a security-adjacent tool: Passport internals are untouched, and all authorization enforcement remains in application code. Internally the package is heavier than a typical Filament resource pack (Clean Architecture use cases, repository contracts with cached decorators, strategy-per-grant-type client factories, DTOs/value objects, domain events). That structure is defensible and makes administrative actions uniform and auditable, but it also means more internal surface area for a team to learn when debugging, for a package with no production dependents.

Hard architectural constraint: v2 delegates schema and scope/grant modeling to a second package, laravel-passport-authorization-core, by the same single author. Adopting this package means adopting a two-package, one-maintainer dependency chain with no dependents and ~11 stars on the primary repo. That is the dominant architectural risk, not the code design.

Integration feasibility. Feasible but narrowly gated. The requirement set — PHP ^8.4/^8.5, Laravel ^12/^13, Passport ^13, Filament ^4/^5 — describes an application that is already bleeding-edge on all four axes. Most organizations are one to three majors behind on at least one. If our stack is not already there, this is not a "small upgrade"; it is a platform modernization project with this package as a tag-along. Within the target stack, integration is clean: a plugin registration, an install command, a published config (passport-ui namespace), and model mapping overrides for custom Passport models. No custom panel required.

Technical risk.

• Vendor concentration: single maintainer, zero dependents, no ecosystem validation, no SLA. Treat as unvetted third-party code, not as infrastructure.
• Silent-config class of defect: changelog 2.4.0 documents a config key that read the wrong namespace and therefore never took effect — a no-op switch that looked configured. That is the failure pattern to expect from low-usage packages: things that appear enabled but aren't. Any flag we depend on must be verified behaviorally, not by reading the config file.
• Audit completeness gap: auditability is delivered via spatie/laravel-activitylog and domain events dispatched only through the package's use cases. Clients created or revoked via php artisan passport:client, direct DB edits, or any path outside the UI will not appear in the trail. For a control being positioned toward ISO 27001-style evidence, that is a material caveat that must be documented in our control narrative, not discovered during audit.
• Compliance framing: the "ISO 27001 audit-ready" badge is marketing. The README itself disclaims certification. Value delivered is traceability of a specific class of administrative action — real but partial.
• Release metadata hygiene: the recorded release date (2026-10-30) should be reconciled against the changelog versions observed; verify actual artifact provenance and tags before pinning.

Key questions.

1. Are we already on PHP 8.4+, Laravel 12+, Passport 13+, Filament 4+? If not, what is the cost of getting there, and is this package the reason or a passenger?
2. Does our Passport deployment use custom models or a non-default token/client schema? If yes, model mapping is custom work with no upstream test coverage for our shapes.
3. Which authorization decisions do we actually need to govern vs. enforce? This package only governs.
4. Can we enforce that all OAuth client lifecycle operations go through the UI (or through the same use cases programmatically)? If not, the audit trail is decorative.
5. What is our acceptable bus factor for a dependency that sits in front of an authentication surface?
6. Do we need self-service mode (2.4.0+), and have we verified owner scoping is enforced server-side rather than only in the form?
7. Build vs. buy: three to four Filament resources over Passport models is roughly days of work. Is the audit/use-case layer worth the dependency, or do we build a thin in-house panel and own it?

Integration Approach

Stack fit. Green-field-adjacent only. This assumes Filament is already the primary admin panel and Passport is already the OAuth server. If either is false, the package is out of scope regardless of its quality. If both are true and the version matrix matches, fit is high — native resources, standard Filament UX, no bespoke panel, plugin-based registration, and locale support (EN/DE) out of the box.

Migration path. Two distinct migrations, and they should not be conflated:

• Into the package (v1 install): composer require + filament-passport-ui:install, publish config, map custom models, run migrations and seeders for passport_scope_resources, passport_scope_actions, passport_scope_grant. Straightforward on a fresh Passport install; on an existing one, the scope seeding step needs a real data-mapping exercise, since free-form scope strings must be modeled as resource:action pairs. That mapping is the actual work, and it is ours, not the package's.
• v1 → v2: schema and optional configuration move to the core package and are no longer published automatically. Documented, but non-trivial, and it introduces the second dependency mid-flight. Start on v2 if starting at all; do not adopt v1 with an upgrade already known to be pending.

Compatibility. Three compatibility surfaces to pin and test: (a) Filament 4 vs 5 — both supported, but pick one and pin; (b) Laravel 12 vs 13 — same; (c) custom Passport model mappings, which are the most likely source of runtime surprises because they are configuration-driven and versioned outside the package's test matrix. Multi-panel installs require per-panel plugin registration and should be verified explicitly.

Sequencing.

1. Spike on a disposable branch/panel with our exact PHP/Laravel/Passport/Filament versions; confirm install command, migrations, and resource boot.
2. Verify every config flag behaviorally (the 2.4.0 bug is the reason). Specifically confirm passport-ui.enable_scopes_management and any self-service setting actually change observed behavior.
3. Confirm the activity log table exists, is migrating cleanly, and records a create/update/revoke cycle with correct causer attribution.
4. Map existing scopes to resource:action pairs; dry-run the seeders against a sanitized copy of production scope data.
5. Define and implement authorization on the resources themselves (Filament policies / panel access) — the package governs OAuth, not who can reach the OAuth admin screen.
6. Lock down out-of-band mutation: restrict passport:client and OAuth table write access to a documented break-glass path, otherwise the audit narrative does not hold.
7. Ship behind a feature flag to a small admin cohort; then widen.

Operational Impact

Maintenance. Budget for dependency-bump lag. With a single maintainer and zero dependents, expect this package to trail Laravel/Filament major releases by weeks-to-months, and treat that lag as a constraint on our upgrade calendar during the adoption period — the tail wags the dog. Pin exact versions, keep a fork ready, and assign a named owner who watches upstream releases and the core-package repo. The internal complexity (use cases, repositories, cached decorators, domain events) means debugging a failure usually starts in our application code and ends inside the package; assume one engineer needs working knowledge of its internals rather than treating it as a black box.

Support. MIT, community-only, GitHub issues, no vendor, no SLA, no security disclosure policy stated. For a package that fronts OAuth client administration, that is a real gap: we need a documented position on how we learn about and respond to a vulnerability in it, and a plan to patch or fork ourselves. Recommend a composer audit / Dependabot hook and a written exception in our third-party risk register.

Scaling. Two scaling surfaces, both ours:

• Token volume: oauth_access_tokens grows unbounded in high-issuance systems. The token resource lists and revokes tokens; at millions of rows the admin table becomes a performance problem and pagination over a large unindexed-ish table is a UX problem. Pair adoption with a pruning job for expired/revoked tokens and confirm index coverage before enabling the token resource on a large install.
• Scope cache: the registry is cached with an explicit invalidation command (filament-passport-ui:cleanup-cache) plus a ClearCacheUseCase. Multi-node deployments need a deploy hook and a post-change hook, or admins will see stale scope state. This is the most likely day-two operational annoyance.

Failure modes.

1. Stale scope cache after out-of-band changes or deploys — symptom is "the scope exists but the UI says it doesn't," which erodes admin trust quickly.
2. Audit trail gaps from CLI/DB-driven client changes — the failure is silent and only surfaces during review. Highest-consequence failure mode given the compliance motivation.
3. Silent no-op configuration (2.4.0 precedent) — a governance toggle appears set, does nothing, and nobody notices.
4. Over-broad access — panel/resource permissions not tightened, exposing OAuth client secrets and token visibility to users who shouldn't have it; self-service mode must be verified server-side, not assumed from the form lock.
5. Irreversible revocation — a mis-click revokes a live integration's tokens. Ensure confirmation UX and that revocation is captured in the audit log with causer identity.
6. Schema drift on v1→v2 — migrations owned by the core package, applied at a different time than the app's own; needs a rehearsed dry run on a production-sized snapshot.
7. Version-matrix lock — the package pins us to PHP 8.4+/Laravel 12+; if we need to hold back a platform upgrade for unrelated reasons, this dependency becomes a blocker.

Ramp-up. Low for engineers already fluent in Filament — the UX follows conventions, no new mental model for day-to-day admin users. Moderate for whoever owns the integration: they need to read the docs, understand the use-case/event layer, and know where the audit log and scope cache live. Estimate a few days for a Filament-fluent engineer to get productive and one to two weeks end-to-end for a safe production rollout including scope mapping, permission hardening, and audit verification — with the caveat that the organizational work (defining scope taxonomy, restricting CLI paths, writing the control narrative) dominates the engineering work. Admin-user training is negligible; auditor-facing documentation of the audit-trail boundaries is not.