Oauth2 Server Public Client Laravel Package

Product Decisions This Supports

• OAuth2 client-architecture decisions: Whether your authorization server should support public clients — SPAs, mobile apps, desktop/CLI tools, and third-party integrations that cannot safely hold a client secret. This package is the upstream building block for that capability inside the Spomky-Labs OAuth2 server stack.
• Build vs. buy on auth infrastructure: If you are assembling your own OAuth2 authorization server in Laravel/PHP rather than buying a managed IdP (Auth0, Okta, Cognito, WorkOS) or adopting a batteries-included package, this narrows the "build" scope to configuration and integration instead of writing public-client handling, secret-less token flows, and PKCE validation yourself.
• Feature scoping for a roadmap item: Concretely answers "can we support our new mobile app / SPA without issuing client secrets?" — a common requirement that otherwise becomes a multi-sprint auth project.
• Ecosystem fit evaluation: Helps decide whether to standardize on Spomky-Labs components across the server and client sides, versus mixing vendors (e.g., League OAuth2 Server or Laravel Passport on the server, a separate client SDK).
• Security posture review: Public clients are the highest-risk OAuth2 surface (no secret to protect); having a maintained component for that path supports a "don't hand-roll crypto-adjacent flows" posture.

When to Consider This Package

Consider it only when all of the following hold:

• You have already committed to spomky-labs/oauth2-server (or the wider Spomky-Labs JWT/OAuth2 component family) as your authorization server foundation.
• You specifically need public-client support (secret-less clients, PKCE) and want it as a composable dependency rather than implementing it in-house.
• Your team can absorb the maintenance and security-review burden of a low-signal dependency (see below).

Look elsewhere — or treat this as a spike only — when:

• Adoption signals are absent. Zero stars, zero dependents, no listed package score: there is no community proof of production use. Treat maturity and long-term maintenance as unproven.
• You are on Laravel Passport or League OAuth2 Server; the ecosystem, docs, and hiring pool are far stronger, and public-client/PKCE support is available there.
• You need vendor-backed SLAs, security advisories, or support contracts — use a managed IdP instead.
• Your team lacks OAuth2/OIDC depth. Public-client flows (PKCE, token binding, refresh-token rotation for secret-less clients) are easy to get subtly wrong; a low-traffic component gives you few reference implementations to learn from.
• Bus factor matters: a single-maintainer component in your auth path is a standing operational risk.

How to Pitch It (Stakeholders)

One-liner for executives: A small, focused PHP component that lets our own authorization server support mobile apps and browser-based clients securely without embedding secrets — relevant only if we choose to build auth in-house on the Spomky-Labs stack.

For engineering: It's the public-client piece of the Spomky-Labs OAuth2 server — the path that handles PKCE and secret-less clients. It saves us from writing that flow ourselves and keeps us inside one component family. The caveat is real: negligible community adoption, no visible dependents, and a single maintainer, so we should treat it as an evaluated dependency with a documented exit path, not a foundational bet.

Recommendation: Do not adopt as a platform decision on adoption signals alone. Run a short time-boxed spike only if we are already on Spomky-Labs and public-client support is on the roadmap; otherwise default to Laravel Passport / League OAuth2 Server for in-house builds, or a managed IdP if auth is not a differentiator. Frame the decision to stakeholders as "auth stack selection," with this package as one input — not as a standalone commitment.