Connect Bundle Laravel Package

Product Decisions This Supports

• Identity & onboarding strategy: Whether to add "Sign in with SymfonyConnect" as a third-party login option. This bundle is the reference implementation of the SymfonyConnect OAuth flow — it tells you the integration surface (routes, scopes, user profile payload, token handling) even if you never install it.
• Ecosystem-targeted acquisition: If the roadmap includes a product aimed at Symfony/PHP developer communities (package registry, CI tooling, job board, conference platform), SymfonyConnect is a low-friction signup path for that audience — it removes a registration step for exactly the users you're courting. This package is the fastest way to validate that demand before committing engineering time.
• Build vs. buy for social login: A concrete data point for the "do we write our own OAuth glue or pull a dependency?" call. Roughly 150–300 lines of league/oauth2-client wiring versus adopting an archived package — this artifact forces the conversation to be explicit about maintenance ownership of auth code.
• Roadmap deprioritization: Given 34 stars, a 2019 last release, and archived status, this supports a "no" recommendation with evidence, freeing the team to spend the sprint on core differentiation instead of a niche IdP.
• Platform extensibility decisions: Whether the product should expose a pluggable identity-provider layer (so customers can wire their own IdPs) rather than hard-coding specific providers — a strategic decision this package's fate usefully illustrates.

When to Consider This Package

• You are on Symfony, not Laravel. This is a Symfony bundle (service container, DI tags, Flex recipe conventions). In a Laravel codebase it cannot be installed as-is; you would be reading it as a specification and reimplementing the flow with Laravel Socialite's custom-provider mechanism. Be honest about that cost before "considering" it.
• Your users are demonstrably Symfony developers. If a meaningful share of your target segment already has SymfonyConnect accounts and your funnel data shows registration friction for them, the marginal value is real. Absent that evidence, the expected login-mix contribution is near zero.
• You need a working reference for the SymfonyConnect endpoint contract. Reading the bundle's provider and user-response mapping is genuinely faster than reverse-engineering the API docs, and it's MIT-licensed so you can port the logic with attribution.
• You are prototyping, not shipping. Acceptable for a spike or internal tool where an unmaintained auth dependency won't face production traffic or a security review.

Look elsewhere when:

• It's a production authentication path. Auth is the highest-blast-radius code you own; an archived dependency with no releases in ~6 years means no security patches, no OAuth spec updates, and no vendor response to a CVE. That risk is disproportionate to the value of one niche login button.
• You need OIDC, PKCE, token rotation, or modern session/refresh semantics — this predates current best practice.
• You are Laravel-first. Prefer Laravel Socialite with a custom provider, or league/oauth2-client with a hand-rolled provider. Both are maintained, and the port from this bundle's logic is small and well understood.
• Your product needs multiple IdPs. Standardize on a maintained abstraction (Socialite, laravel/socialite + socialiteproviders/*, or an IdP-agnostic broker) rather than accumulating single-provider bundles.
• Compliance or SSO requirements exist (SOC 2, enterprise procurement). Niche consumer-style IdPs rarely satisfy enterprise identity expectations; expect to add Google/Microsoft/Okta anyway.

Recommendation: Treat this as documentation, not a dependency. Port the ~200 lines of SymfonyConnect OAuth logic into a Socialite custom provider if the ecosystem bet is validated; otherwise close it out.

How to Pitch It (Stakeholders)

For executives: This is a small, archived Symfony add-on that lets users sign in with their SymfonyConnect (Symfony developer community) account. It is not usable directly in our Laravel stack and has had no maintenance since 2019, so adopting it would put an unpatched dependency directly on our login path. The strategic question it raises is worth one decision: is the Symfony/PHP developer segment large enough in our funnel to justify a dedicated login option? That is a research question, not an engineering one — answer it with signup-funnel data, and if the answer is yes, we implement it in ~1–2 days inside Laravel Socialite with a maintained, owned code path. Recommendation: do not adopt; retain as reference; revisit only with segment data.

For engineering: Do not add symfonycorp/connect-bundle to composer.json. It's a Symfony bundle (wrong framework, wrong DI model), archived, and its last tagged release predates current OAuth guidance. If we pursue SymfonyConnect login, implement it as a laravel/socialite custom provider backed by league/oauth2-client — the bundle's ConnectProvider/user-response mapping is a clean, MIT-licensed reference for the endpoint contract, which is the only durable value here. Budget roughly 1–2 days including tests, and treat the token/state handling as security-sensitive: review it, own it, and add a regression test against the live endpoint.