Oauth2 Interface Laravel Package

Product Decisions This Supports

• Build vs. buy on authorization infrastructure. This package is a contract set, not a working OAuth2 server: it defines interfaces (clients, access/refresh tokens, authorization codes, scopes) that an implementation must satisfy. It informs the decision only if you are evaluating a custom or self-hosted authorization server in PHP — it does not, by itself, deliver any OAuth2 capability.
• Architecture lock-in / portability of your auth layer. Choosing code that programs against these interfaces means your domain code depends on spomky-labs contracts rather than on league/oauth2-server contracts (the de-facto PHP standard, and what Laravel Passport and the Symfony OAuth2 bundles are built on). This is a roadmap-level decision about who owns your auth abstractions.
• Roadmap scoping for compliance work. If a roadmap item is "support OAuth 2.1 / PKCE / OIDC / FAPI," note that this package contributes nothing toward conformance, security hardening, token lifecycle, or grant-type handling. It shifts zero compliance work off your plate — relevant when sizing an epic.
• Informing a "maintain our own server" spike. Useful as a reading input for engineers designing a hexagonal/ports-and-adapters auth service, if the team wants a reference for how token/client/scope abstractions were modeled in the Spomky-Labs ecosystem.
• Not a factor in feature delivery. With zero dependents, no stars, and no implementations shipped here, it does not move any customer-facing feature, integration, or partnership timeline. It should not appear as a line item in a delivery plan.

When to Consider This Package

Consider it only if all of the following hold:

• You are already inside the legacy Spomky-Labs OAuth2 Server suite (oauth2-server, oauth2-client, related HTTP factories) and need the shared contracts those packages type against — i.e., a maintenance/upgrade task on an existing codebase, not a greenfield choice.
• You are deliberately designing a framework-agnostic authorization abstraction and want to evaluate several interface definitions before committing to your own.
• Your team has the appetite to own the entire implementation lifecycle (grant flows, token storage, revocation, key rotation, security patches) because interfaces give you no behavior.

Look elsewhere — decisively — in essentially every other case:

• Default Laravel answer: Laravel Passport (builds on league/oauth2-server) covers authorization code + PKCE, password, client credentials, personal access tokens, scopes, and ships migrations, guards, and middleware. It is the low-risk, high-support baseline.
• First-party / third-party API auth with less ceremony: Laravel Sanctum for token-based API auth where full OAuth2 is overkill.
• Standards-complete or enterprise requirements: league/oauth2-server directly, or a managed IdP (Auth0, Okta, Keycloak, Cognito, WorkOS) if OIDC, SSO, MFA, SCIM, or audit/compliance obligations are on the roadmap.
• Symfony-adjacent teams: the actively maintained OAuth2 bundle ecosystem, not this interface package.

Risk signals a PM should factor in: no stars, no dependents, and a package whose only content is interfaces implies negligible community validation and no support surface. Treat it as unmaintained until proven otherwise; assume no security-response SLA and no upgrade path. Dependency-health review should flag it as avoid for new work.

How to Pitch It (Stakeholders)

For executives (one line): This is a set of PHP interface definitions for an OAuth2 server — a blueprint with no engine. It does not give us login, tokens, or security out of the box, and almost nobody in the ecosystem uses it. Recommendation: do not adopt; use Laravel Passport or a managed identity provider, which we can support, audit, and staff for.

For engineering leads: The package supplies contracts (Client, AccessToken, RefreshToken, AuthorizationCode, Scope) from the Spomky-Labs ecosystem. It is interface-only, has no dependents, and no observable community traction — so adopting it means writing and owning 100% of the implementation while taking on a non-standard dependency. The pragmatic path is league/oauth2-server via Passport (Laravel) or direct league/oauth2-server contracts, which are widely used, maintained, and already aligned with the Symfony/Laravel tooling our team knows. Revisit this package only if we inherit a Spomky-Labs codebase and need to keep it compiling.

Framing the trade-off for the room: OAuth2 is security-critical infrastructure; the cost is not in the interfaces but in the maintenance, patching, and conformance burden. We should spend our engineering budget on product differentiation, not on re-implementing a token server against an interface library with no community behind it. Buying (Passport) or outsourcing (managed IdP) reduces risk and time-to-market; building against this package maximizes both.