Oauth Bundle Laravel Package

Product Decisions This Supports

• Directly: essentially none. This is a thin Symfony bundle that glues HWIOAuthBundle's OAuth flow to RzUserBundle's user model. It ships no providers, no UX, no security primitives, and no Laravel integration. It does not unlock a feature, a roadmap item, or an integration on its own.
• Indirectly, as an input to three decisions:
  • Migration scoping — if it appears in a dependency tree, the real finding is "this app coupled social login to a bespoke user bundle (RzUserBundle) via HWIOAuthBundle." Scope the replacement around that identity coupling, not around the shim. The shim is trivia; the coupling is the work.
  • Tech-debt and risk register — archived, zero stars, zero dependents, no maintainer. Book it as a liability line item with an owner, a security review, and a removal date. Auth is a security boundary, so "abandoned glue" is a risk with teeth, not just clutter.
  • Build-vs-buy governance — this is the canonical cautionary tale: a "buy" decision that resolved to a zero-community package, i.e., someone built it, shipped it, and left. Use it as the worked example when ratifying a dependency policy (adoption threshold, maintenance-status check, maintainer count, license check, CVE-response expectation).
• Decisions it must not be attached to: greenfield social login, SSO roadmap items, identity-platform selection, or any claim that it is an "accelerator" for auth work. For "add Google/GitHub/Apple login," the answer is Laravel Socialite (Laravel) or a maintained OAuth2 client plus our own user provider (Symfony) — not a resurrected shim.
• One reusable product idea worth lifting: the provider-identity → local-user mapping (lookup by (provider, provider_user_id), else match by verified email, else create; plus a distinct "connect/link" flow separate from "login"). That's a ~40-line pattern in a maintained stack, and it's the only thing here worth carrying forward.

When to Consider This Package

Consider reading it — never adopting it — only when:

• You have inherited a legacy Symfony app where rz/oauth-bundle, HWIOAuthBundle, and RzUserBundle are already installed, and you need to understand the wiring before replacing it.
• You are doing dependency archaeology on a codebase whose original authors are gone and need to know what a given class actually does.
• You are writing a migration or exit plan and need to enumerate the exact integration surface (DI config, service definitions, user provider, firewall wiring) so nothing is silently dropped on removal.

Look elsewhere — decisively — when:

• The work is greenfield or on an active roadmap. Archived status means no security patches, no PHP/Symfony compatibility updates, and nobody to ask when it breaks.
• You need support guarantees, CVE response, or license clarity. Verify the license independently; an archived repo with zero stars is not a compliance-approved dependency for an auth path.
• The stack is Laravel. This is a Symfony bundle, not a Laravel package. A Laravel codebase cannot use it without an adapter layer that would be pure cost. Use Laravel Socialite.
• You are on a supported runtime. It targets the Symfony 2/3-era HWIOAuthBundle API, and HWIOAuthBundle itself is effectively end-of-life. Upgrading Symfony will eventually force you off this bundle and both parents in one migration.
• Adoption signal matters. Zero stars, zero dependents, no recent commits: no community validation, no second opinion, no prior art to search when it fails.

Decision rule: treat "archived + zero dependents" as a hard stop for new adoption. The only exception is read-only reference during a migration, or a fork-and-own arrangement with a named internal owner, security review, and a funded exit date.

How to Pitch It (Stakeholders)

One-liner: An archived, single-purpose glue package with no users and no maintainer — not an adoption candidate, an item to remove.

For executives: We evaluated rz/oauth-bundle as an option for social/OAuth login. It is abandoned (archived), has zero measured adoption, is a Symfony bundle (so it is not usable in our Laravel stack without costly adaptation), and depends on packages that are themselves effectively end-of-life. For an authentication path, that means security-patch risk and support risk with no offsetting benefit. Recommendation: do not adopt. If it already exists in our codebase, add it to the modernization backlog as a low-effort removal with a named owner.

For engineering: It only wires HWIOAuthBundle's social-login flow into RzUserBundle's user model — no standalone value, and it fails confusingly (missing-service errors) unless both parents are configured. The replacement path is a maintained OAuth2 client plus an in-house user provider: Laravel Socialite on our stack, or league/oauth2-client / Symfony's authenticator system if we stay on Symfony — or a managed identity provider if we want to stop owning this entirely. Migration cost sits mostly in the user-model coupling, not the shim, so scope the work as "decouple identity from RzUserBundle," not "swap a bundle."

Framing the trade-off: the real question isn't whether this package is good — it isn't viable. It's whether we want to own identity plumbing at all. If yes, own it on a maintained foundation with a documented exit path. If no, that's a buy decision for a managed identity provider. This package is not a step toward either outcome; it's a detour.

Ask: approve the dependency-governance rule (no new adoption of archived or zero-adopter packages, especially on auth paths), and if applicable, a small timeboxed spike to inventory existing usage, confirm the pinned Symfony/HWIOAuthBundle/RzUserBundle versions, and schedule removal behind an application-level auth adapter.