Oauth2 Laravel Package

Product Decisions This Supports

• Build vs. buy for OAuth2 — with a strong "buy, but not this" conclusion. OAuth2 is commodity infrastructure. The real decision this package surfaces is not "should we write our own OAuth2 server" (almost always no) but "which maintained implementation do we standardize on." psx/oauth2 is a useful data point in that comparison, not a leading candidate.
• Whether we need to be an OAuth2 provider at all. The package bundles both consumer (client) and provider (server) roles, which forces a genuinely valuable product question: do we need to issue tokens to third parties, or do we only need to consume identity from Google/GitHub/Okta? Most products only need the consumer half — that alone can remove 60–80% of the integration scope and the associated security review burden.
• Roadmap input for partner/API access. If the roadmap includes "let partners call our API on behalf of a customer," an OAuth2 provider with scopes and refresh tokens is the enabling primitive. This package is a reference for scope granularity and grant-type coverage, even if we implement with something else.
• Scope and consent UX decisions. Consumer-side OAuth2 forces explicit decisions about which scopes we request, how we store refresh tokens, and what happens on revocation — decisions that are cheap to make up front and expensive to retrofit.
• Risk-calibrated adoption decision. With 0 stars and 0 dependents, this is effectively unvetted code. The PM-relevant output is a rejection with rationale recorded for future re-evaluation, not a spike ticket.

When to Consider This Package

Reasonable to consider only if:

• The codebase already runs on the PSX framework (Apioo's stack). This is a PSX-ecosystem package, not a framework-agnostic library with a Laravel service provider — adopting it in a Laravel app means writing and owning the glue (container bindings, config, PSR-7/HTTP kernel bridging).
• You need both consumer and provider roles from a single dependency and want them behaviorally consistent.
• Apache-2.0 is a hard requirement and the alternatives' licenses are incompatible.
• You have engineering capacity to fork and maintain the package internally — treat it as source code you are adopting, not a dependency you are consuming.
• You are prototyping or building an internal-only tool where a security incident has bounded blast radius.

Look elsewhere if:

• You are on Laravel. Use laravel/passport (provider), laravel/socialite (consumer), and laravel/sanctum (first-party token auth). These are maintained, documented, and have the hiring/onboarding advantage of being what every Laravel developer already knows.
• You need OpenID Connect, not just OAuth2. OIDC (ID tokens, discovery, userinfo) is what "Sign in with Google" actually requires in practice; plain OAuth2 gets you authorization, not authentication.
• Security-critical production surface. OAuth2 implementations are a high-value target; the vulnerability classes (redirect URI validation, PKCE handling, token leakage) are subtle. A package with zero dependents has had essentially no external scrutiny.
• You need active maintenance, CVE response, or community support. Single-maintainer, low-adoption packages carry bus-factor and abandonment risk that must be priced in explicitly.
• You need compliance evidence (SOC2 vendor review, security questionnaire answers). No dependents means no downstream audit trail to lean on.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated psx/oauth2, an Apache-2.0 PHP library that implements both the client and server sides of OAuth2. It is technically competent but effectively unadopted — zero GitHub stars and zero dependent projects — and lives in a niche PHP framework ecosystem rather than ours. My recommendation is not to adopt it. OAuth2 is well-served by mature, widely-deployed libraries in the Laravel ecosystem (passport, socialite, sanctum), which cost us less in integration, hiring, and security review. The strategic decision worth funding is narrower: confirm whether we need to issue tokens to third parties or only consume third-party logins — that scoping choice saves more time than any library selection.

For engineering (the real ask): Don't budget for integration; budget for a security review. Anything we ship on the auth path needs PKCE, strict redirect-URI allowlisting, short-lived access tokens with rotation, and a revocation story. psx/oauth2 gives us the protocol mechanics but not the framework integration, the OIDC layer, or the maintenance guarantee — so we'd own the wrapper and the patch stream. If we need provider capability, laravel/passport is the default; if we only need social login, socialite plus a thin token-storage policy is roughly a one-sprint item.

Framing to avoid: presenting this as "we found a library." It isn't a find — it's a negative result that de-risks a decision. The deliverable is a recorded rationale and a pointer to the maintained alternative, so the question doesn't get re-litigated next quarter.