Hybridauth Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy scoping for social login. This package is a concrete data point for the “Sign in with Google/GitHub/Facebook” decision. It demonstrates what a thin social-authentication integration surface looks like — provider config, start/callback endpoints, session round-trip, account linking, token storage — which helps a PM scope the feature independent of the artifact.
• Framework-fit validation (correcting the brief). Despite being framed as a Laravel package, this is a Symfony bundle (DI extension, bundle class, services.yml, Symfony security firewall integration). For a Laravel roadmap this is a category error, not a version bump. This assessment should update the intake record and prevent a wasted spike.
• Roadmap risk classification for identity features. 25 stars, zero dependents, health score ~0.47, and a dependency on the end-of-life HybridAuth 2.x. Auth is a security-critical path, so this artifact should be classified as do-not-adopt and, if present anywhere, flagged as technical debt with a migration ticket.
• Reference architecture for an in-house or first-party build. Useful as a pattern library — how providers are configured, how the two-state callback flow is structured, how the session is handled across redirects — to accelerate a Socialite (Laravel) or direct-HybridAuth/league-oauth2 (Symfony) implementation.
• Account-linking as a first-class requirement. The bundle returns a provider profile and stops; persistence is the product team's job. This supports decisions on the social_accounts data model, identity collision handling (same email across providers), and whether to defer to a managed IdP.
• Deprecation and migration planning. If any legacy service uses this, the assessment supports a freeze-and-migrate plan rather than expanding reliance.

When to Consider This Package

Consider it only when:

• You are maintaining a legacy Symfony 2.x/3.x application where this bundle is already installed and working, and the cost/risk of removal exceeds the cost of leaving it frozen pending a scheduled migration.
• You need a read-only reference for how HybridAuth was wired into a Symfony container (config schema, endpoint shape, session handling) to prototype your own integration faster.
• You are doing landscape due diligence and want to see the bundle-era approach before committing to a modern path.

Look elsewhere in the default case:

• Laravel target: use Laravel Socialite — first-party, maintained, session-integrated, provider coverage that matches the common set. This bundle cannot boot outside a Symfony kernel without a bespoke shim.
• Modern Symfony (5/6/7): use knpuniversity/oauth2-client-bundle (league/oauth2-client) or HWIOAuthBundle, or call the HybridAuth library directly. This bundle’s conventions target the Symfony 2/early-3 era and will not wire cleanly.
• Security, compliance, or SSO requirements apply (they nearly always do for auth): unmaintained packages with near-zero adoption are a poor fit for production OAuth, token exchange, or identity linking. You would own every bug and every provider-policy change.
• You need provider parity, support, or an SLA: none exists here. Zero dependents means there is no community surfacing defects before you do.

Verdict: Do not adopt for new work and do not plan Laravel work around it. Use it as reference material and a legacy-migration candidate.

How to Pitch It (Stakeholders)

For executives (one paragraph):

Customers expect “Log in with Google/Microsoft/GitHub,” and that feature is worth roadmapping. However, the package under review is a Symfony bundle, not a Laravel package, and its health signals — 25 stars, zero downstream dependents, a low maintenance score, and a dependency on the end-of-life HybridAuth 2.x — make it unsuitable as a production dependency on a security-critical path. Recommendation: deliver social login through first-party options (Laravel Socialite on Laravel; maintained Symfony bundles or direct HybridAuth on Symfony, or a managed identity provider), use this package only as a design reference, and, if it already exists in our estate, freeze it and schedule a migration. Feature: yes. This package: no.

For engineering:

• Framework mismatch, stated plainly: “Bundle” means Symfony. Do not estimate Laravel work against it; the correct analogue is Socialite.
• Risk profile: low adoption, no active maintainer commitment, no advisory pipeline — we would own the code, the CVEs, and the on-call incidents.
• Cheapest safe path: Socialite (Laravel) or league/oauth2-client / HWIOAuthBundle (Symfony), with provider abstraction and account linking as a first-class requirement, not an afterthought.
• If already in use: inventory providers and call sites, pin versions, wrap HybridAuth behind a small internal SocialAuthProvider interface so domain code is insulated, add contract tests against each provider’s callback, then cut over provider-by-provider with a rollback flag and decommission the dependency.
• Timeline expectation: plan roughly one engineering sprint to build the abstraction layer and callback tests before the team can safely operate the existing integration — and treat that engineer as a key-person risk until the replacement lands.

One-line decision: Social login is a real roadmap item; this abandoned Symfony bundle is not the way to deliver it.