Novassport Laravel Package

Technical Evaluation

Verdict: do not adopt as a dependency. Fork/vendor it or replace it with ~200 lines of in-house Nova tooling. This is a thin presentation layer over Laravel Passport's data model, not a system with meaningful depth. That makes it cheap to replace and makes its abandonment a governance problem rather than an engineering one.

Architecture fit. The package only fits a narrow three-way intersection: the application runs Laravel, has adopted Laravel Nova (paid, per-site license), and uses Passport rather than Sanctum for API auth. Laravel's own guidance has moved new projects to Sanctum, and Passport is now positioned for genuine OAuth2-server requirements (third-party clients, authorization-code flows, scopes). A 66-star, single-purpose Nova tool for that intersection describes a small tail of the ecosystem, which is consistent with the low opportunity score. If any of the three legs is missing, this package has zero surface area for us.

Integration feasibility. Mechanically trivial: composer require kristories/novassport, register the tool in NovaServiceProvider::tools(), ensure migrations for oauth_clients / oauth_access_tokens exist, and grant Nova users access. Realistic effort is hours, not days. The blocker is not effort — it is that the last release is January 2022, which predates Laravel 10/11/12 and Nova 5. Expect the Composer constraint set to conflict with a current stack and require either a --with-dependencies fight or a fork. Treat "install it and run the test suite" as a research spike, not a plan.

Technical risk.

• Silent functional breakage from Passport itself. Passport 11 moved to hashed client secrets, meaning the plaintext secret is not recoverable after creation. Any UI affordance that displays or re-copies an existing client secret is structurally broken against modern Passport, independent of whether the package installs. Validate this before anything else; it may invalidate the package's core value proposition.
• Security-sensitive surface. The tool renders OAuth client IDs, secrets, and token inventories inside the admin panel. That is a privileged, high-blast-radius view. It inherits Nova's authorization, but we would want an explicit gate/policy on the tool and audit logging, plus confirmation that secrets are never written to logs or serialized into Nova responses beyond the create step.
• No upstream response path. No maintainer SLA, no CVE monitoring, no security advisories. For a component that touches credential material, that is the decisive risk, not code quality.
• Dependency drift. Nova is a paid, closed-distribution package with its own major cadence; a stale Nova tool is a recurring upgrade tax paid at the worst time.

Key questions to resolve.

1. Do we actually need an OAuth2 authorization server, or would Sanctum satisfy the requirement? (If Sanctum, this whole line of work disappears.)
2. Are we committed to Nova long-term, and at which major version?
3. Does the business require the ability to view/retrieve client secrets after creation, or only at creation time?
4. Who is the audience for this UI — internal operators or tenant-facing admins? What is the blast radius of a mis-clicked revoke or a leaked secret?
5. What is our Laravel/Nova upgrade cadence, and do we have appetite to own a fork indefinitely?
6. Is there an existing internal admin convention (custom Nova tools, Filament, etc.) this would fragment?

Integration Approach

Stack fit. Only proceed if the answer to Q1 is "Passport, yes" and Q2 is "Nova, yes." Otherwise stop — the correct integration is no integration. If we do proceed, scope it as an internal operator console feature, not a customer-facing capability, and gate it behind an explicit Nova gate and role.

Migration path. There is no meaningful migration from anything; this is greenfield UI over existing Passport tables. Two viable paths:

• Fork and vendor (recommended if we need the UI now). Fork the repo into our org, pin to our Laravel/Nova/Passport versions, add a test for the secret-hashing behaviour, add an authorization gate, and publish it as a private Composer package (or a path repository). Because the package is small, this is a day or two of work and converts an unowned dependency into an owned one.
• Rebuild in-house (recommended if we have any doubt). A Nova tool exposing client CRUD and token revocation against oauth_clients / oauth_access_tokens is a small, well-understood amount of code. We control the secret-display semantics, the audit trail, and the upgrade path. Given the package's size, this is likely cheaper over a two-year horizon than the fork.

Avoid the third path — consuming the public package as-is on a current stack — because it leaves us with an unmaintained dependency on a credential-handling surface and no upgrade story.

Compatibility. Establish a version matrix before committing: Laravel major, Nova major, Passport major, PHP version. Assume the published constraints are stale and that we will be widening them ourselves. Test specifically against hashed-secret Passport behaviour and against Nova's current tool-registration API.

Sequencing.

1. Requirements spike: confirm Passport-vs-Sanctum, confirm secret-retrieval requirement, confirm Nova licensing and version.
2. Two-day technical spike: fork, install against our actual stack, run client CRUD + token revoke + secret creation end-to-end.
3. Security review of the tool's data exposure and Nova gate configuration.
4. Decide fork-vs-rebuild based on spike friction; either way, ship as an internally owned artifact with a named owner.
5. Roll out to staging with a seeded non-production Passport client; only then to production operators.

Operational Impact

Maintenance. The dominant cost. The package has no upstream maintainer cadence, so we become the maintainer the moment we adopt it. Budget a recurring line item for keeping the fork aligned with each Laravel/Nova/Passport major — realistically small in hours, but it must be scheduled, not discovered during an upgrade fire. Without a named owner, this rots and becomes a blocker at the next framework bump.

Support. No vendor, no community of scale, no security advisories. Internal tickets route to whoever owns the fork. Document the fork's divergence from upstream in the README so a future engineer doesn't try to "just upgrade to the latest release."

Scaling. Operationally negligible. This is an admin-panel read/write over a handful of tables; request volume is bounded by operator headcount, not API traffic. The risk is not load, it is inventory scale — an org with thousands of tokens needs pagination, filtering, and search that a 66-star tool likely does not provide. Check this before assuming it scales with tenant count.

Failure modes.

• Silent breakage on framework upgrade — tool fails to register, or the Nova page 500s, and nobody notices until an operator needs it.
• Secret-handling regression — a Nova upgrade or Passport upgrade changes what the UI can display, producing confusing operator behaviour around credentials.
• Mis-scoped authorization — tool exposed to a wider Nova user set than intended, granting token-revocation or client-creation rights to the wrong people.
• Orphaned credentials — revoked/deleted clients leaving tokens in oauth_access_tokens without a clear cleanup story; verify whether the tool handles cascade or leaves us with a manual sweep.
• Upgrade collision — Nova major upgrade blocked because the fork wasn't bumped, creating pressure to rush a security-sensitive change.

Ramp-up. Low for any engineer already fluent in Laravel and Nova — an afternoon to read the source and understand the Passport schema. The real ramp-up is domain knowledge: OAuth2 client/grant/scope semantics and the security implications of the admin surface. Do not let "it's just a CRUD panel" justify skipping the security review; the panel's contents are credentials.

Bottom line. Low technical complexity, high governance cost, and a security-sensitive surface with no upstream. Adopt only behind a fork we own, or replace it with in-house tooling. Either way, this is a small, bounded piece of work — the mistake would be treating the public package as a zero-cost dependency.