Oauth2 Interface Laravel Package

Technical Evaluation

Architecture fit. spomky-labs/oauth2-interface is a contracts-only library: it ships PHP interfaces (and a few supporting traits) describing OAuth2 domain objects — clients, access tokens, refresh tokens, authorization codes, scopes. It contains no concrete implementation, no ServiceProvider, no facade, no config, no migrations, and no middleware. In a Laravel application it does nothing on its own. Its only possible role is as a type-hint vocabulary for a custom-built OAuth2 authorization server — which is a build-vs-buy decision that has already been settled decisively by the ecosystem in favor of league/oauth2-server and laravel/passport.

Integration feasibility. Composer-installable, but that is the entire out-of-the-box experience. To get any value, a team must supply implementations for every interface: entity classes, repositories, token persistence, grant validation, revocation, and PSR-7 request/response plumbing. There is no documented Laravel binding path. The integration effort is unbounded and open-ended, which is the worst possible shape for a dependency in a product roadmap.

Technical risk.

• Abandonment. The Spomky-Labs OAuth2 server family was archived; the maintainer publicly redirects users to league/oauth2-server. Adopting an archived contract layer means inheriting a contract you cannot evolve.
• Zero adoption signal. Zero stars and zero dependents is not a soft signal — it means no downstream projects have validated these interfaces against real grant flows, no issue triage exists, and there is no security response process.
• Version skew. Packages of this vintage carry PHP 5.6/7.x constraints. Modern Laravel (10/11/12) requires PHP 8.1+, so Composer resolution will likely fail or force an unacceptable downgrade of the framework.
• Design generation gap. The contract set predates the PSR-7/PSR-15-centric design now standard in league/oauth2-server; bridging it to Laravel middleware would be hand-rolled.

Key questions.

1. Is this package referenced anywhere in composer.json, composer.lock, or source (grep for the namespace)?
2. If used, is it used only as type hints, or are there in-house implementations behind it that constitute real logic?
3. What is the business driver for a custom authorization server versus Passport/Sanctum?
4. Which grant types and RFCs (6749, 6750, 7636 PKCE, 7662 introspection) must be supported, and does anything in the current stack actually implement them?

Assessment: do not adopt. The correct target state is laravel/passport (full OAuth2 server) or laravel/sanctum (first-party token issuance), both of which are actively maintained and Laravel-native.

Integration Approach

Stack fit. Poor. Laravel's supported answers are Passport (wraps league/oauth2-server, provides migrations, guards, scopes, and a full authorization server) and Sanctum (SPA/mobile first-party tokens). This package sits underneath neither and would require a bespoke bridge.

Migration path.

• If unused (expected): remove from composer.json, run composer update, verify no autoload references, deploy through the normal pipeline. Low risk, one-PR change.
• If used as type hints only: replace hints with league/oauth2-server entity interfaces, or drop them entirely.
• If in-house implementations exist behind it: treat as a scoped replacement project. Map each interface to its league/oauth2-server equivalent, port token tables, and preserve existing token values through the cutover so live sessions are not force-invalidated.

Compatibility. Assume Composer-level incompatibility with PHP 8.1+/Laravel 10+. Validate this first — it may collapse the decision to "remove" immediately. There is no PSR-7/PSR-15 alignment, so middleware integration is manual regardless.

Sequencing.

1. Confirm actual usage (composer manifest + namespace grep + runtime check).
2. Decide: remove (likely) vs. replace (only if a custom server is genuinely in flight).
3. If replacing, freeze feature work on the OAuth surface and scope the Passport migration.
4. Migrate token/client tables, dual-read during cutover, then decommission.
5. Add a regression suite over login, refresh, revoke, and scope-enforcement flows before the cutover, not after.

Operational Impact

Maintenance. None available. No releases, no maintainer SLA, no backlog. Keeping it means forking it, which converts a public dependency into permanent in-house code ownership — the single most expensive outcome for a TPM to sign off on.

Support. The community channel is effectively dead. Issue searches, Stack Overflow answers, and blog guidance will be stale and will point at an implementation that no longer exists.

Scaling. Not applicable at the interface layer. All scaling concerns — token storage growth, revocation lists, refresh-token rotation, key rotation, per-client rate limits — land entirely on whatever implementation the team hand-rolls. That is where the real operational risk concentrates.

Failure modes.

• Composer resolution breaks on the next PHP or Laravel upgrade, blocking routine maintenance.
• Silent security drift: no CVE feed, no advisory coverage, no patch path for OAuth2-relevant issues.
• Bus factor 1 → 0: the original author has moved on and the wider ecosystem has moved to a different design.
• Wiring errors: interfaces compile but resolve to no implementation at runtime, producing auth failures in production that unit tests did not catch.

Ramp-up. Low to read the interfaces; high to actually ship. Engineers would learn RFC 6749/6750/7636 semantics from scratch instead of inheriting a hardened, widely deployed implementation, and would own that knowledge permanently.

Recommendation. Reject as a dependency. Standardize on Passport for third-party OAuth2 and Sanctum for first-party tokens, and treat any existing reference to this package as technical debt with a dated removal ticket.