Oauth Laravel Package

Product Decisions This Supports

• Admin-surface acceleration, not core auth. cortex/oauth is a frontend layer — CRUD screens for managing OAuth clients, scopes, and tokens sitting on top of the underlying OAuth server package. It is a candidate for the "who builds the back-office screens?" decision, not the "how do we authenticate API traffic?" decision.
• Build vs. buy for internal admin CRUD. Evaluating it forces the useful question: do we hand-roll client/scope management screens (a few days of Laravel resource work), or adopt a pre-built layer? At ~0 adoption and archived status, the honest answer is that "build" is roughly the same cost as "buy + integrate + fork."
• Cortex/Rinvex ecosystem consolidation. Only relevant if the roadmap already commits to the Rinvex Cortex modular stack; this package is a component of that suite, so the decision is really "stay in the suite" vs. "exit the suite."
• Multi-module / multi-tenant API management. Where the product needs per-module or per-tenant OAuth client ownership, a modular frontend has some conceptual fit — but the same outcome is achievable with first-party Laravel tooling.
• Not a fit for: consumer-facing login, social sign-in, token issuance strategy, or anything touching PCI/regulated auth flows.

When to Consider This Package

Consider only if all of the following hold:

• The codebase is already on the Rinvex Cortex stack and this package closes an existing gap.
• You need an internal, low-traffic admin UI for OAuth client/scope records and are comfortable owning it.
• You will fork and pin it — treat it as vendored source, not a dependency. Archived + 2 stars + 0 dependents means no upstream fixes, no security patches, no compatibility guarantees with current Laravel/PHP versions.
• Someone is explicitly named as maintainer for the fork, with a budget line for keeping it current.

Look elsewhere if any of these are true (most cases):

• Greenfield API auth: Laravel Sanctum for first-party/SPA tokens, Laravel Passport (or league/oauth2-server directly) for full OAuth2 server behavior — both are actively maintained, documented, and hireable-for.
• You need the admin UI specifically: Passport's client-management UI or a Filament/Nova resource over your own models will be better supported and fit your existing admin patterns.
• Social/federated login: Laravel Socialite — different problem entirely.
• Any compliance, audit, or long-lived production surface: archived packages are a liability. A dependency that will never receive a CVE patch is a risk decision your security review should veto by default.
• Star count and dependent count are being used as a proxy for quality: here they're a genuine signal. Two stars and zero dependents means effectively no community validation and no one to ask when it breaks.

Verdict: Do not adopt for new work. If it's already in the tree, treat it as technical debt with a migration ticket — the surface area is small enough that replacing it with first-party CRUD is a low-risk, well-scoped project.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed Laravel package that provides ready-made admin screens for managing OAuth API clients. The catch is decisive: it is archived, has essentially no users, and receives no updates. Adopting it converts a small build cost into an indefinite maintenance and security-patching obligation with no upstream support. Recommendation: do not adopt; fund a short internal build on Laravel's maintained auth packages instead. This costs marginally more up front and materially less over the product's life.

To engineering: It's a thin CRUD frontend over an OAuth server package within the Rinvex Cortex suite — the auth logic lives elsewhere, so this is UI scaffolding, not security-critical code. Upside is a few days saved. Downside is a pinned, unmaintained dependency that will drift from current Laravel/PHP releases and will not get security fixes. If you're already on Cortex, fork it, vendor it, and assign an owner; otherwise use Passport or Sanctum plus a Filament resource and move on.

One-line framing: Right idea, wrong time — the problem it solves is real and small, and it's now cheaper to solve it with maintained first-party tooling than to inherit an abandoned package.