Oauth Bundle Laravel Package

Product Decisions This Supports

• A "no" on adoption — and that is the decision it most cleanly supports. With 0 stars, 0 dependents, no maintainer signal, and a description that contradicts the code (marketed as a Laravel package, but structurally a fork of the Symfony HWIOAuthBundle), this should not anchor a roadmap, a build-vs-buy call, or an architecture commitment. Treat it as a signal to re-evaluate the auth stack decision on its merits, not as a shortcut to close the ticket.
• A useful forcing function on "what do we actually need?" The package's advertised surface — authorization code, client credentials, password, and refresh token grants; scoped access tokens; Eloquent-backed clients — describes two very different products often confused in planning: an OAuth 2.0 authorization server (issuing tokens for our own APIs) versus an OAuth client / social login (letting users sign in via Google, GitHub, Apple). The description claims the former; the HWIOAuthBundle lineage is the latter. That confusion is a roadmap-level risk worth resolving before any sprint is scoped against "OAuth."
• Build vs. buy, restated. Buy — but buy from a maintained source. On Laravel, the credible paths are (a) Laravel Socialite + socialiteproviders/* for login, or (b) Laravel Passport / Sanctum for first-party API authorization (if we truly need to issue tokens). For Symfony, upstream HWIOAuthBundle. A zero-adoption fork is not a "buy"; it is an unbounded maintenance liability mislabeled as a dependency.
• Where it earns a place in the decision record: reference material. The Resource Owner classes (provider-to-user field mappings) are MIT-licensed and genuinely useful as a specification for writing Socialite custom providers. Extracting them is a code-reading and adaptation task, not a dependency decision — and that distinction should show up in the plan.
• Roadmap impact of adopting it. We would inherit the fork's release cadence, security patching, PHP runtime compatibility, and Symfony-version constraints — with no upstream to lean on. Every future Laravel upgrade becomes a fork-maintenance task owned by us, on the single highest-blast-radius surface in the product (authentication).

When to Consider This Package

Adopt (or extract from) only if all of the following hold:

• You are on Symfony and have deliberately chosen to fork upstream HWIOAuthBundle for a reason you can state in one sentence — e.g., an internal IdP that upstream will not accept.
• You have read the diff against upstream and can enumerate what "Extended" actually changes. The package description does not tell you, and no changelog was provided.
• You have someone to own it: patch capacity, CVE tracking, and the discipline to cut releases. A 0-star/0-dependent project has no external maintainer to rely on.
• Security review has signed off on OAuth flow handling — client secret storage, PKCE, state/nonce, token introspection, and refresh-token rotation — because this code sits directly on the login path.
• For the reference-only use case: you want a catalog of provider quirks (scopes, endpoints, response field mappings) to inform Socialite custom providers, and you will vendor the extracted classes with attribution rather than depend on the package.

Look elsewhere — and you almost certainly should — when:

• You are on Laravel. Use Socialite (login) or Passport/Sanctum (issuing tokens). This artifact is a Symfony bundle; it is the wrong framework for the job no matter what the description says.
• You need maintained OAuth support with a real CVE response posture. Zero stars and zero dependents means zero external pressure to fix a vulnerability.
• You need standards-compliant, audited OAuth 2.0 / OIDC rather than an unaudited fork of a client library. Consider league/oauth2-client with a first-party provider, or a managed IdP (Auth0, WorkOS, Cognito, Clerk) if SSO is not your differentiator.
• You need an SLA or vendor accountability. There is none.
• Your team's PHP skills are Laravel-shaped. Symfony DI/security/firewall conventions are non-transferable knowledge and would need to be learned purely to satisfy a dependency.

How to Pitch It (Stakeholders)

For executives: We evaluated spawnrad/oauth-bundle and recommend against adopting it. It is an unmaintained, zero-adoption fork of an existing Symfony library — advertised as a Laravel package, but not one — with 0 GitHub stars, 0 dependents, and no vendor support. Authentication is the highest-risk surface in the product; a dependency nobody is watching is a liability, not a shortcut. The real cost isn't the install — it's permanently owning a fork on our login path, across every future framework and PHP upgrade. Recommendation: proceed with a maintained, framework-appropriate option — Laravel Socialite (+ socialiteproviders) if the need is social/SSO login, or Passport/Sanctum if the need is issuing tokens for our own APIs. We can still harvest the fork's provider classes as reference material under its MIT license.

For engineering: Two concrete points to take into the sprint. First, framework mismatch is disqualifying as a runtime dependency — this ships Symfony Bundle classes and DI/security wiring, not an Illuminate\Support\ServiceProvider; Composer's Laravel package discovery will not register it, and pulling it in will fight Laravel's pinned symfony/* transitive versions. Second, maintenance risk is structural — 0 stars / 0 dependents means we are the only consumer and own every future CVE, every Symfony major bump, and every provider API change. Proposed path: (1) inventory the IdPs we actually need and map each to a Socialite core driver, a socialiteproviders driver, or "unsupported"; (2) for the gap, implement Socialite's AbstractProvider (getAuthUrl, getTokenUrl, getUserByToken, mapUserToObject) using this repo's Resource Owner classes as the field-mapping spec, vendored into our namespace with attribution; (3) if that's insufficient, open a PR upstream first, and only fork into our repo with a named owner and a documented diff. Any runtime adoption of the Symfony bundle inside the Laravel app should require an explicit, written architecture exception — ideally isolated as a separate Symfony service behind an HTTP boundary, never loaded into Laravel's container.