Nova Passport Manager Laravel Package

Technical Evaluation

Architecture fit. This is admin-plane tooling, not authentication infrastructure. The package contributes a Laravel Nova tool plus resource screens over Passport's oauth_clients and oauth_access_tokens records — create/edit/delete clients with grant types and redirect URIs, browse and revoke personal access tokens, copy client IDs and secrets. It belongs in the "operator convenience" layer, and only on a stack already running Laravel + Nova (paid license) + Passport. The architecturally useful artifact for a TPM is the boundary it draws: it covers the CRUD layer of OAuth administration (provisioning, inspection, rotation, revocation) and none of the policy layer (approvals, scope governance, audit trails, multi-tenancy, partner self-serve registration). That boundary lets us ship a stopgap now and keep governance as separately funded, explicitly scoped roadmap items rather than hidden scope buried inside an "admin UI" ticket.

Integration feasibility. Mechanically trivial: Composer require, register the tool in NovaServiceProvider::tools(), clear caches. The real feasibility question is the version matrix. The only compatibility evidence is release 0.9.0 (2024-04-24) adding Laravel 11 via a community contribution; Nova 4/5 and current Passport majors are unevidenced, and with 25 stars and zero dependents there is no downstream usage to infer from. Treat "it installs and renders on our pins" as unproven until a timeboxed spike proves it.

Technical risk. High, and concentrated in the least comfortable place — code that reads client secrets and access tokens.

• Archived, single maintainer. No compatibility fixes, no security response, no triage. Unmaintained is tolerable for a formatting helper; it is not tolerable for an OAuth credential surface without an internal owner.
• Secret handling. If Passport::hashClientSecrets() is enabled, secrets are stored hashed and cannot be re-displayed. A UI that assumes a retrievable secret will either render nothing useful or mislead an operator into believing a rotation succeeded. Verify before enabling hashing, and design the rotation runbook around it.
• Authorization is ours. Do not assume an adequate hook ships here. Gate registration with a Gate::check around tool registration and add Nova policies; a Nova user who isn't an OAuth administrator must not reach these screens.
• Model assumptions. Confirm the tool queries Passport::useClientModel()-configured classes rather than hard-coded Passport models, or a fork with custom models breaks silently.
• No audit trail. Every mutation is unattributed unless we add logging — which matters for incident review after a leaked token is revoked.

Key questions.

1. Which Nova major does the tool support, and does it register cleanly on ours?
2. Which Laravel and Passport majors are in scope — does the 0.9.0 Laravel 11 bump imply Nova 4 only?
3. Does it display client secrets or raw token values, and how does it degrade under secret hashing?
4. Is there any built-in authorization, or must we gate registration and author policies ourselves?
5. Does revocation actually invalidate issued tokens server-side, and does deleting a client invalidate its tokens?
6. Will we fork and name a maintainer, with pinned versions and tests around issuance and revocation?
7. Is a two-resource custom Nova implementation, or a maintained alternative, cheaper than ownership?
8. Is Passport even the right choice — if the need is first-party token auth only, Sanctum removes this problem class.

Integration Approach

Stack fit. Adopt only into an existing Laravel + Nova + Passport environment. Do not buy a Nova license to support one screen; a Blade/Livewire admin or a documented artisan-command runbook is cheaper. If Nova isn't already our internal admin surface, close the item here.

Migration path. Consume it as a fork candidate and reference implementation, not an upstream dependency. Vendor the code into our namespace, pin the version, commit the lockfile, wrap it behind an internal-admin gate, and keep a documented exit path to a purpose-built Nova resource. The package's small surface is itself the most valuable output: if the only gap is "ops needs a screen to issue, inspect, and revoke clients and PATs," the build estimate is one or two Nova resources — that bounds buy-vs-build tightly and lets us price the fork honestly.

Compatibility. Run a hard-timeboxed non-production spike (roughly 3–5 days for a Laravel/Nova developer). Validate: Composer constraint resolution against our PHP/Laravel/Nova/Passport pins; service provider and tool registration; any published config or migrations; Nova sidebar rendering; and query behavior against our actual Passport schema, including custom models. Do not infer compatibility from the 2024 release date or the Laravel 11 line alone.

Sequencing.

1. Confirm use cases and operators — client provisioning and rotation, token inspection, revocation for support. If the only need is a one-time personal access client during setup, use passport:client and close the item.
2. Confirm the version matrix and run the spike outside production.
3. Security review: authorization gating, secret exposure under hashing, audit logging, revocation semantics, client-deletion behavior.
4. Make an explicit, documented adopt-as-fork / rebuild-minimal / decline decision with a named owner.
5. If adopting: pin and test the fork, publish an internal runbook and ownership, roll out to internal administrators only, and document per-environment client rotation so downstream teams receive new credentials before old ones retire.

Operational Impact

Maintenance. Archived status transfers all maintenance to us. Budget recurringly for Nova and Laravel major-upgrade compatibility, Passport schema and API drift, security patches, and regression tests covering token issuance and revocation. This is a line item, not a one-time integration cost — if we can't fund it, we shouldn't adopt it.

Support. Community support is effectively absent; there is no upstream to escalate to. Prerequisites before production: internal documentation, a named owner, and an escalation path. The business case should be stated operationally — support or ops can revoke a leaked token or onboard a partner integration without a DBA running SQL against oauth_clients/oauth_access_tokens and without an engineer dropping to php artisan passport:client on a production shell. That recurring saving is real and should be priced against the fork cost, not against zero.

Scaling. The admin UI is low-scale, but oauth_access_tokens grows quickly and unboundedly. Verify pagination, search, and query efficiency in both listings against realistic volumes, and confirm revocation performance. Reject any screen that loads an unbounded token list — a slow admin query against a large token table shares a database with production API traffic.

Failure modes. Expect Nova major-upgrade breakage; Passport schema/API drift; Composer constraint conflicts; missing or misconfigured authorization letting a non-admin Nova user manage OAuth clients; accidental secret exposure in the UI or browser history; incomplete revocation leaving tokens live; no audit trail complicating incident review; and orphaned code after team turnover. The security-relevant three — authorization, secret exposure, revocation — each need an explicit automated test before rollout, not a manual check.

Ramp-up. A Laravel/Nova developer reads the code in an afternoon; it is thin and conventional. The ramp-up cost that matters is organizational, not technical: an owner must be named and funded, an internal runbook written, operators trained on rotation under secret hashing, and the decision recorded so the package isn't silently depended on long after its context has been forgotten. Plan for that ownership transfer explicitly — it is the difference between a two-week stopgap and an unowned credential surface in production.