Oauth2 Server Client Manager Supervisor Laravel Package

Product Decisions This Supports

• Build vs. buy for auth plumbing. This is not a product; it's a ~one-interface composition layer for Spomky-Labs' OAuth2 server. It lets you register several ClientManager implementations and have lookups resolved against them in order, instead of hard-wiring a single source of OAuth clients. The build-vs-buy call is really "do we vendor a small abandoned helper, or write the same decorator ourselves in a day?"
• Roadmap: auth client migration / strangler pattern. The one genuinely interesting product capability here: run a legacy client store (config file, old DB table, hardcoded array) alongside the new one, with the supervisor probing them in priority order. That buys an incremental cutover of client credentials instead of a big-bang auth rewrite — valuable if you have live integrations you can't break.
• Multi-tenant and white-label packaging. If "which OAuth clients exist" is per-tenant, per-brand, or per-partner business configuration, a supervisor lets you compose a tenant-scoped manager over a global one without forking the auth server.
• Partner / federation onboarding. A read-only manager backed by a partner registry or config-as-code can be layered above your primary store, so onboarding a partner doesn't require a deploy of your auth service.
• Use cases it fits: B2B API platforms, enterprise SSO rollouts, marketplace integrations — anywhere client registration is an operational workflow rather than a code change.
• What it should not drive: any greenfield auth strategy, any "should we build an IdP" decision. Zero stars, zero dependents, no release signal means there is no ecosystem evidence to bet a roadmap on.

When to Consider This Package

Consider it only when all of these are true:

• You are already running spomky-labs/oauth2-server (itself deprecated) and cannot justify migrating the token endpoint yet.
• You have a concrete, near-term need for more than one client source — legacy + new store, or global + tenant-scoped.
• You've confirmed your PHP/Laravel versions are still supported by the underlying stack, and you're willing to pin and vendor the dependency.

Look elsewhere when:

• Greenfield. Use league/oauth2-server, Laravel Passport/Sanctum, or an external IdP (Keycloak, Auth0, Cognito, WorkOS). No reason to inherit a dead tree.
• Single client source. You don't need a supervisor; you need one repository. A supervisor over one manager is pure indirection.
• You can express it as a decorator. If your need is "try A, fall back to B," that's ~50 lines behind your own ClientManager adapter. Owning that code is cheaper than owning a supply-chain risk.
• Security/maintenance is a hard requirement. No stars, no dependents, no apparent activity: assume unmaintained. OAuth client resolution is an auth boundary — an unpatched dependency there is a governance problem, not just a code smell.
• You need audit trails, rate limiting, or admin UI for clients. This package does none of that; budget for the surrounding product work separately.

How to Pitch It (Stakeholders)

To executives: This is a narrow glue component, not a platform investment. Its only strategic value is a migration pattern — letting us move OAuth client registrations from the old store to the new one gradually, with fallback, so customer-facing integrations don't break on cutover day. Cost to adopt is small; so is the support guarantee, which is why we'd vendor it rather than depend on it.

To engineering: One contract, one composite. It implements the ClientManager interface and probes delegates in order, so auth code stays untouched while we change where clients live. The catch is that the package is effectively abandoned upstream (deprecated parent library, no adoption signals), so the proposal is: pin the version, wrap it behind our own adapter interface, and schedule replacing the composite with our own implementation within a sprint or two. Treat the dependency as a temporary scaffold, not an architecture.

Decision requested: Approve a time-boxed spike to confirm it works on our PHP/Laravel baseline, contingent on a documented exit plan to in-house the composite.