Oauth2 Server Public Client Laravel Package

Technical Evaluation

Architecture fit. spomky-labs/oauth2-server-public-client is not a Laravel package. It is a framework-agnostic, PSR-oriented component that plugs into the broader spomky-labs/oauth2-server authorization-server stack. Its role is narrow: it supplies the "public client" concept from RFC 6749 (§2.1, §2.3) — clients that cannot hold a secret (SPAs, mobile apps, CLI tools) — so that the token endpoint treats token_endpoint_auth_method=none correctly and authorization-code exchange relies on redirect-URI binding plus PKCE rather than client authentication. Nothing in that description requires or benefits from Laravel's container, config, or Eloquent.

For a Laravel codebase, this creates an immediate impedance mismatch. The framework already ships two first-party answers — Passport (full OAuth2 authorization server on top of league/oauth2-server, with PKCE support) and Sanctum (first-party SPA/mobile tokens). Adopting this package means adopting an entire parallel server stack plus a glue layer, to reach a capability Passport already exposes.

Integration feasibility. Feasible only as a deliberate, non-trivial integration project: bind the upstream server's PSR-7 request/response cycle into Laravel's HTTP kernel, source the client repository from Eloquent, wire grant types, and add the public-client authentication handler. That is a multi-week effort for a capability available out of the box, and it introduces a second OAuth implementation into the codebase alongside whatever Passport/Sanctum already covers. Feasibility is high in the abstract and low in expected value.

Technical risk. This is the dominant concern, and it is severe:

• Abandonment. The Spomky-Labs OAuth2 server line was superseded in the ecosystem by league/oauth2-server and is effectively end-of-life. A satellite package with the parent dormant inherits that status.
• Zero adoption signal. Blank star count, score 0, and 0 dependents are not cosmetic. OAuth is a security-critical surface; a library with no downstream users has no one stress-testing edge cases, no CVE reports flowing in, and no community patch velocity.
• Supply-chain exposure. Unmaintained Composer packages are a standing risk — abandoned-flag handling, transitive dependency drift (PSR-7 implementations, web-token/JWT siblings), and no security disclosure process.
• PHP/platform drift. Dependency constraints from that era will likely conflict with modern PHP and Laravel releases, forcing --ignore-platform-reqs or version pinning that compounds over time.
• Correctness surface. Public-client handling is exactly where OAuth implementations get subtly wrong — PKCE downgrade, redirect-URI prefix matching, refresh-token rotation for unauthenticated clients.

Key questions. (1) What specific requirement is this package believed to satisfy that Passport + PKCE or Sanctum does not? (2) Is the parent spomky-labs/oauth2-server still receiving security patches, and what is the documented disclosure path? (3) Which PHP and Laravel versions do the transitive constraints actually resolve against? (4) Is this a greenfield server, or an existing Spomky deployment being ported to Laravel — the latter is the only scenario where the calculus changes? (5) Who on the team owns ongoing security triage for a third-party auth stack?

Integration Approach

Stack fit. Poor, unless the organization is already standardized on Spomky-Labs. The package assumes PSR-7/PSR-15 middleware semantics and a server object assembled by hand; Laravel assumes its own request lifecycle and service container. Bridging is possible (Laravel speaks PSR-7 via Symfony's bridge) but the seam is permanent maintenance overhead, and every Laravel upgrade reopens it.

Migration path. The recommended path is not to migrate to this package at all. For a Laravel product:

• First-party SPAs and mobile apps → Sanctum.
• Third-party or delegated authorization, including public clients → Passport, configured with PKCE (Passport::enablePasswordGrant is unrelated; PKCE is enabled per-client via public clients with enablePkce). Passport already models public clients as public = true clients with no secret, and enforces PKCE for them.
• Already running Spomky-Labs elsewhere → plan a forward migration off it to league/oauth2-server (directly or via Passport), not a lateral move that deepens the dependency.

If the package is nonetheless mandated, treat it as a bounded adapter: isolate all Spomky types behind an internal OAuthServer interface, register bindings in a dedicated service provider, and forbid Spomky classes from leaking into controllers, models, or jobs. That containment is what makes a later exit tractable.

Compatibility. Expect friction across three axes: PHP version constraints (likely predating PHP 8.x type semantics), Laravel's HTTP kernel vs. PSR-7 middleware ordering, and the PSR-7/PSR-17 implementation the parent library expects. Validate all three with a throwaway spike before any estimate is committed. Confirm the license (typically MIT) clears legal review.

Sequencing. If proceeding: (1) spike the dependency resolution and a single authorization-code + PKCE round trip end-to-end; (2) implement client storage and the public-client handler behind the internal interface; (3) build conformance tests for the negative cases — code replay, PKCE mismatch, redirect-URI mismatch, refresh rotation; (4) gate rollout behind a feature flag with dual-running against Passport for one release; (5) only then expose to real clients.

Operational Impact

Maintenance. Effectively self-maintained from day one. With 0 dependents there is no upstream community to absorb fixes; the team inherits the package's defects plus the parent library's. Budget for a named owner and a standing quarterly review to re-evaluate viability. Contrast this with Passport, where Laravel's release cadence carries the security burden.

Support. No vendor, no active maintainer community, no documented SLA. Internal escalation is the only path, which means the on-call rotation must include someone fluent in OAuth internals and the Spomky object graph — a scarce and expensive skill to concentrate on a low-adoption library.

Scaling. The token endpoint is high-QPS-adjacent (every session, every refresh) but computationally cheap; scaling is about the client repository and key handling, not this package. The real scaling constraint is operational: adding grant types, client metadata, or consent flows means forking or monkey-patching, because there is no upstream to accept contributions.

Failure modes. Ranked by expected impact: (1) silent security regression — a public-client or PKCE flaw that passes happy-path tests and is discovered in a pentest or incident; (2) dependency deadlock — a transitive constraint blocks a PHP or Laravel upgrade, freezing the platform; (3) abandoned-package supply-chain event — the vendor name becomes available or a malicious successor is published; (4) knowledge concentration — the one engineer who understood the integration leaves; (5) drift from first-party tooling — mixed auth stacks produce inconsistent token semantics and confusing incident response. Mitigations: pin exact versions with a committed composer.lock, subscribe to advisories for the whole transitive tree, and keep the adapter interface as a documented exit ramp.

Ramp-up. Two to three weeks for an engineer already comfortable with OAuth 2.0 and PSR-7; materially longer for anyone else, because documentation for a zero-adoption package is thin to nonexistent and the parent library's docs are the real (and stale) reference. Compare to roughly one day for Passport + PKCE on an existing Laravel app.

Bottom line. The package is architecturally coherent but commercially and operationally orphaned. For a Laravel product, the expected value is negative: it duplicates first-party capability while importing EOL and security-critical dependencies with no support surface. Recommend rejecting adoption and documenting the decision, unless an existing Spomky-Labs deployment makes this a transitional step — in which case scope it as a bridge with a funded exit to league/oauth2-server, not as a destination.