Oauth2 Laravel Package

Product Decisions This Supports

• Build vs. buy for OAuth client integration. adoy/oauth2 is a ~thin wrapper — a few hundred lines around token exchange and authorization redirects. Reviewing it is a cheap way to scope what "build it ourselves" actually costs. If the estimate is small, you may not need a dependency at all; if it's large, that argues for a maintained library, not this one.
• Authentication and third-party integration strategy. Directly informs decisions about how the product connects to Google, GitHub, Facebook, or partner APIs — social login, "Sign in with X," and delegated API access. Maps to roadmap epics for onboarding and account linking.
• Legacy triage: keep, wrap, or replace. If a codebase already depends on this package, the assessment feeds a migration-versus-maintenance decision. Given its spec vintage (OAuth 2.0 draft-15, pre-RFC 6749), it belongs on a technical-debt register with a retirement path, not on a new-feature backlog.
• Security and compliance posture. Draft-era clients can miss requirements that are now table stakes — PKCE, strict redirect URI validation, token rotation, OIDC. This informs whether the product can credibly claim modern auth hygiene to enterprise buyers or during a security review.
• Vendor and dependency risk. 393 stars, zero dependents, and no active maintenance signal means bus-factor risk and no upstream patches. Useful input for a dependency-approval policy.
• Licensing review. LGPL-2.1 triggers legal review in many commercial orgs. This is a fast, concrete decision point for legal and for whether the package can ship in a closed-source distribution.
• Reference architecture, not production dependency. Its real PM value is as a comparison point when evaluating league/oauth2-client or Laravel Socialite — a benchmark for scope, not a candidate for adoption.

When to Consider This Package

Consider only if:

• You are maintaining a legacy PHP application that already uses it, and a rewrite is not on the table this quarter — in which case isolate it behind an interface so it can be swapped later.
• You are on an old PHP runtime where modern libraries will not install, and the integration is a single, low-risk provider.
• You need a minimal, readable implementation to learn from or to prototype a flow in an afternoon, with no production exposure.

Look elsewhere if:

• You are starting a new Laravel application. Use Laravel Socialite for social login; use league/oauth2-client plus a provider package for general OAuth 2.0 client work; use Laravel Passport or Sanctum if you are issuing tokens rather than consuming them.
• You need RFC 6749 conformance, PKCE, OpenID Connect, refresh-token rotation, or modern grant types. A draft-15 implementation will not cover these.
• You need active maintenance, security patches, or a responsive maintainer — there is no evidence of any.
• LGPL-2.1 is incompatible with your distribution model or your legal team's policy.
• Your threat model includes OAuth-specific attacks (redirect URI manipulation, mix-up, token leakage). Do not inherit an unaudited draft implementation.

Adoption gate: maintained within the last 12 months, spec conformance documented, license cleared, tests covering token exchange and error paths, and a named owner. This package fails at least three of those.

How to Pitch It (Stakeholders)

To executives: We evaluated adoy/oauth2, a lightweight PHP OAuth 2.0 client. Recommendation: do not adopt for new work. It is built against a 2011 draft of the OAuth specification rather than the ratified standard, shows no active maintenance, and carries an LGPL-2.1 license that adds legal overhead. The cost of adopting it is not the integration — it is the eventual migration plus the security review we would have to run to justify it. Standardizing on Laravel Socialite and league/oauth2-client gives us the same capability with active maintenance and a permissive license, at effectively the same integration cost.

To engineering: It is a thin wrapper — useful as a scope reference, not as a dependency. It predates RFC 6749, so expect gaps around PKCE, redirect URI validation, and token rotation, and assume no upstream security patches. It also has zero dependents on the registry, which means no ecosystem pressure to fix anything. If you find it in an existing codebase, wrap it behind an internal auth interface and schedule replacement; do not extend it. If you are considering building in-house, this is a fair estimate of the floor — and the floor is low enough that the real question is maintenance, not effort.

To legal: LGPL-2.1 requires review before it goes into anything we distribute. Given there is a permissively licensed, better-maintained substitute, that review is avoidable cost.

Bottom line: low opportunity, low urgency. Log it as a rejected option with rationale, and spend the decision energy on which maintained client library becomes the house standard.