Oauth2 Server Utils Laravel Package

Product Decisions This Supports

• Build vs. buy for token-endpoint plumbing: This package targets the plumbing layer of an OAuth2 authorization server — parsing and validating PSR-7 requests for authorization, token, and introspect/revoke endpoints, extracting typed grant parameters (grant_type, client_id, code, redirect_uri, scope, PKCE verifier, etc.), and normalizing errors before they hit your grant handlers. That's a "buy" decision you only make once, and only if the surrounding server implementation is already chosen.
• Architecture standardization around PSR-7/PSR-15: If your platform mandate is PSR-compliant HTTP middleware (Slim, Mezzio, Laminas, Laravel via a PSR-7 bridge), utilities like this reduce glue code and keep request handling testable without spinning up a full kernel. That's a decision about your HTTP contract, not about OAuth2 itself.
• Roadmap scoping for auth work: Adopting this only makes sense if a roadmap item is "stand up or extend an OAuth2 authorization server." It does not support decisions around OIDC, social login, SSO, or delegated API access — those belong to league/oauth2-server, web-token/jwt-framework, or a hosted IdP.
• Use cases where it genuinely fits: internal/hobby authorization servers, an educational or reference implementation, a thin adapter over an existing Spomky-Labs OAuth2 server, or a narrow utility for validating inbound OAuth2-shaped requests against a spec test suite.
• Use cases where it does not fit: anything customer-facing, anything in a regulated or security-audited scope, anything with a multi-year support horizon, or any product where you'd be the only consumer of the dependency in production.
• Ecosystem signal as a decision input: The package sits in the older Spomky-Labs OAuth2 lineage, which was largely superseded — the PHP community consolidated on league/oauth2-server for authorization servers and web-token/jwt-framework for JWT/JOSE. Zero recorded dependents and no star signal in this snapshot is a strong "do not standardize on this" input, regardless of code quality.

When to Consider This Package

Consider it only when all of the following hold:

• You are already committed to a Spomky-Labs-based OAuth2 server stack and this fills a specific, well-understood gap rather than being the foundation.
• Your team is comfortable owning the dependency long-term — vendoring it, pinning it, or forking it if upstream goes quiet.
• You need request-parsing/normalization semantics that match a specific OAuth2 RFC reading and you'd otherwise hand-roll ~500 lines of validation you'd have to test yourself.
• The scope is internal, low blast radius, and a security review of the actual source is feasible in hours, not weeks.

Look elsewhere when:

• You need a production authorization server. Default to league/oauth2-server, which has active maintenance, broad adoption, framework integrations, and an ecosystem of grant extensions.
• You need OIDC, JWT, JWKS, or key rotation. Use web-token/jwt-framework (same author lineage, actively maintained) or a vetted IdP.
• You want to buy rather than build. Auth0, Okta, Keycloak, Cognito, or WorkOS remove an entire class of security-engineering risk that no utility package can absorb for you.
• Supply-chain hygiene is a hard requirement. Zero dependents and no adoption signal means no downstream community pressure to catch regressions or disclose issues. In an auth path, that matters more than in a formatting library.
• You need documented support windows, security policy, or SLAs. Not expected here.
• A maintained alternative exists for the same job — check league/oauth2-server's request/authorization-request handling and laminas-diactoros/nyholm/psr7 for parsing before committing.

Net PM read: treat this as a reference implementation and reading material, not a dependency. Green-light a short engineering spike to mine it for validation rules and edge cases; red-light adding it to composer.json in a customer-facing service.

How to Pitch It (Stakeholders)

One-line summary: A small PHP utility library for parsing and validating OAuth2 server requests — technically focused, but with no visible adoption, no dependent ecosystem, and a lineage that the PHP community has largely consolidated away from. We should not standardize on it.

For executives: We evaluated it as a shortcut for OAuth2 endpoint plumbing. It saves perhaps a few days of low-level validation work, but it introduces a single-maintainer, zero-adoption dependency directly in our authentication path. The cost of a security incident or an unmaintained dependency in auth vastly exceeds the days saved. Recommendation: no adoption; if we need an authorization server, we scope it around a maintained library or a hosted identity provider, both of which we can support contractually.

For engineering: The package handles PSR-7 request parsing for authorization/token endpoints — the boring, error-prone part of OAuth2. The code is likely fine; the problem is everything around it. Zero recorded dependents means no one else is exercising these code paths in production, so we'd effectively be the maintainer. league/oauth2-server covers the server side, and web-token/jwt-framework covers the JWT side, both with real adoption. Proposed action: a 1–2 day spike to harvest the request-validation rules and RFC edge cases into our own thin layer or into our chosen library's extension points, then move on. If anyone proposes adding it as a direct dependency, escalate to a security review first.

Risk framing to keep on the record: OAuth2 is a security contract, not a convenience API. Dependencies in that path must clear a higher bar — active maintenance, documented disclosure process, and evidence of real-world use. This package does not clear that bar on the evidence available.