Nova Passport Manager Laravel Package

Product Decisions This Supports

• Build-vs-buy scoping for OAuth administration. This package is a thin Nova UI over Passport's client and token tables — create/edit/revoke clients, inspect and copy client IDs and secrets, edit redirect URLs and grant types. Its real value to a roadmap conversation is as a bound on the in-house estimate: if the only gap is "ops needs a screen to issue, inspect, and rotate clients and personal access tokens," that is roughly one or two Nova resources — a contained piece of work, not a platform initiative. Use it to price the build, not to justify a strategic buy.
• Separating the CRUD layer from the governance layer. The package cleanly covers provisioning, secret rotation, and revocation. It covers none of approvals, scope policy, audit trails, multi-tenancy, or partner self-serve registration. That boundary is the most useful artifact it produces: ship the stopgap now, and keep governance as explicitly funded, separately scoped roadmap line items rather than hidden scope buried inside an "admin UI" ticket.
• A recurring operational cost avoidance case. The concrete business justification is that 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 saving recurs every month; price it against the fork-and-own maintenance cost, not against zero.
• An auth-strategy gate, decided early. If Passport is not the OAuth2 server — for example, first-party SPA/mobile auth handled by Sanctum — this item closes rather than defers. Making that call before grooming prevents an "admin UI for auth we don't run" backlog artifact.
• Ecosystem signal, not a bet. 25 stars, zero dependents, archived since April 2024, single maintainer, last release 0.9.0 adding Laravel 11 via community contribution. Treat this as a validated shape of the problem and a fork candidate. Do not anchor a multi-quarter roadmap, a compliance workflow, or a partner-facing portal on it.

When to Consider This Package

Consider it when:

• You are already standardized on Laravel + Nova (paid license) + Passport, and the need is an internal-only admin screen for a small number of operators.
• You need a stopgap in days with a small blast radius, and you are prepared to fork or vendor the code rather than depend on upstream.
• You want a reference implementation to copy patterns from before writing your own Nova resource. For many teams this is the highest-value use, even if the package itself never ships — the small surface area is itself the scoping signal.
• You have a named internal owner and a funded maintenance line for Nova/Laravel major upgrades, Passport schema drift, and security patches.

Look elsewhere, or build in-house, when:

• Compatibility is unverified. Archived with no maintainer means Nova 4/5 and current Laravel/Passport majors are not guaranteed; the Laravel 11 bump in 0.9.0 is the ceiling of evidence. Timebox a spike before committing.
• You are not on Nova. Buying a Nova license to support one screen is rarely justifiable; a Blade/Livewire admin or a documented artisan-command runbook is cheaper.
• You need governance features — role-based access, approval workflows, audit logging, multi-tenancy, or public client registration. None of that ships here.
• You require security patching. Code that reads client secrets and access tokens is exactly where an unmaintained dependency is least acceptable; a fork means accepting that obligation explicitly, with an owner.
• Passport is not the right fit. If you only need first-party token auth, Sanctum removes this problem class entirely and the roadmap item should be closed.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost accelerator for internal OAuth administration — roughly one to two sprints of UI work saved, if we already run Laravel Nova and Passport. The caveat is material: the project is archived, has 25 stars and zero downstream dependents, and is a one-maintainer effort whose last release was April 2024. Frame it as a design reference and fork candidate, not a strategic dependency, and do not build compliance or partner-facing workflows on top of it. Recommendation: fund a short, time-boxed spike (about a week of a Laravel/Nova developer) only if API access management is already on the roadmap; otherwise close the item and revisit when governance work is actually funded. Budget the fork as a recurring maintenance line, not a one-time integration cost — if we can't fund that, we shouldn't adopt it.

For engineering: It is a thin Nova tool wrapping Passport's client and token models — likely a handful of files, registered in NovaServiceProvider::tools(). Plan to fork it into our namespace, pin versions, commit the lockfile, add tests around token issuance and revocation, and gate every screen behind Nova authorization policies — register the tool conditionally via a Gate::check, not for every Nova user. Validate in a non-production spike: the PHP/Laravel/Nova/Passport version matrix, hashClientSecrets() behavior (a UI that assumes retrievable secrets will mislead operators into thinking a rotation succeeded), whether it queries Passport::useClientModel()-configured classes rather than hard-coded models, whether revocation actually invalidates issued tokens server-side, and pagination against realistically large oauth_access_tokens volumes. Add audit logging — every mutation is otherwise unattributed, which matters in incident review after a leaked token is revoked. Do not consume it as an unmodified upstream dependency. If any of the above fails, the fallback is a first-party Nova resource: a contained piece of work, not a rewrite.