Connect Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the premise needs correcting. sensiolabs/connect-bundle is a Symfony bundle, not a Laravel package. It is built around Symfony-specific extension points: a bundle class registered in bundles.php, a DI extension with a sensiolabs_connect: configuration tree, a security firewall factory (sensiolabs_connect as a firewall type under security.firewalls), a UserProviderInterface implementation, and event dispatcher hooks. Laravel has no equivalent bundle concept, no security firewall factory registry, and uses service providers plus Auth guards and Socialite drivers. None of the bundle's integration surface transfers. The only genuinely portable artifact is its underlying SDK, sensiolabs/connect, which is a Guzzle-based, framework-agnostic OAuth2 client — and even that is a transitive dependency we would consume directly rather than through this bundle.

Integration feasibility — not installable, but readable. Installing this package into a modern Laravel app will fail or force unacceptable downgrades: its Composer constraints sit in the Symfony 3.x/4.x and PHP 7.x era, which conflict with Laravel 9+/PHP 8.x and its Symfony 6/7 components. Even if forced in, symfony/security-bundle cannot coexist meaningfully with Laravel's auth stack. The realistic use is as a reference implementation: read its authorization-URL construction, token exchange, and /api/users/me profile fetch, then reimplement the ~200 lines of actual logic against Socialite or league/oauth2-client.

Technical risk — high, concentrated in three areas. (1) Abandonment: archived, last release September 2019, no security patching, no PHP 8 support; any adoption means owning a fork. (2) Adoption signal: 34 stars and zero dependents indicate effectively no community, no Stack Overflow corpus, no third-party fixes to borrow. (3) Upstream service risk: SensioLabs Connect is an external SaaS identity/badge provider; its long-term availability is outside our control, and login-via-Connect is a hard dependency on that service being up. MIT licensing is the one clean item here.

Key questions for the business.

• Is SensioLabs Connect actually a product requirement, or was it inferred from a legacy integration? Who is the user segment that needs it?
• Do we need authentication (login), badge/profile verification via the API, or both? They have very different scopes.
• Is the Connect service still provisioned for our org, and do we have api_key/api_secret and a confirmed redirect URI?
• Has anyone checked whether Socialite or league/oauth2-client already covers this in ~2 days of work?
• What is the cost of not doing this versus the cost of maintaining a bespoke OAuth driver forever?

Integration Approach

Stack fit. Target stack is Laravel 10/11 + PHP 8.2+, with laravel/socialite as the social-login abstraction. Socialite supports custom drivers cleanly via Socialite::extend() or Socialite::buildProvider(), and its AbstractProvider already handles the authorization-code grant, state validation, and token exchange. That is the correct home for this functionality; the Symfony bundle is not.

Migration path. Do not install sensiolabs/connect-bundle. Instead: (1) implement a SensioLabsConnectProvider extends AbstractProvider with getAuthUrl, getTokenUrl, getUserByToken, and the required scopes; (2) map the Connect profile payload to a social_accounts table (provider, provider_user_id, access_token, refresh_token, expires_at, raw_profile) rather than mutating users; (3) if badge/API data is needed post-login, wrap sensiolabs/connect — or plain Http with a token — behind a small ConnectClient service with caching; (4) expose config via config/services.php and .env, never hardcode credentials. Optionally, the bundle's user-provider and event-listener code serves as a checklist for edge cases (account already linked, email collisions, token refresh).

Compatibility. Pin nothing from this package. Validate that whichever Connect SDK or hand-rolled client we choose supports PHP 8.2+, Guzzle 7, and Laravel's HTTP client conventions; if sensiolabs/connect itself is stale, a ~150-line direct HTTP client against the documented endpoints is lower risk than adopting its dependency tree. Run composer why-not as a sanity check before any spike.

Sequencing. (1) Confirm the requirement and obtain Connect API credentials — this is the real blocker, not code. (2) Half-day spike: authorize → callback → profile fetch in a scratch Laravel app. (3) Decision gate: proceed only if the spike works and the service is confirmed live. (4) Production driver, token storage, and account-linking flows. (5) Feature-flag the driver so it can be disabled without a deploy if Connect has an outage. (6) Document the "we deliberately did not use connect-bundle" rationale in the ADR so it is not re-litigated.

Operational Impact

Maintenance. Everything is ours. There is no upstream to patch, no release cadence, no security advisories. A bespoke Socialite provider is roughly 150–250 lines plus tests — a sustainable, auditable footprint. Forking or vendoring the Symfony bundle is the opposite: a permanent, low-value maintenance tax on code we did not write and cannot upgrade.

Support. No vendor, no maintainers, no community. Internal support means one or two engineers who understand OAuth2 and the Connect API; that is a bus-factor of two and should be recorded in the runbook. Abandoned-package warnings from Composer and SCA tooling will also generate recurring noise if the package is referenced anywhere.

Scaling. Negligible load: OAuth flows are per-login and trivially cacheable. The only scale-relevant concerns are the Connect API's rate limits and latency on profile/badge lookups — mitigate with a short-TTL cache on profile data and a circuit breaker so Connect degradation degrades only the Connect login path, not the whole auth surface. Token storage should be encrypted at rest; that is a compliance obligation, not a scaling one.

Failure modes. Connect outage → login failure for that provider only (acceptable if other auth methods remain). Token expiry/revocation → silent 401s unless refresh or re-auth is implemented. API schema drift → deserialization errors with no upstream changelog to warn us. Attempting to install the bundle → Composer resolution failure or, worse, a partially working install that breaks composer update for the whole team. Service decommissioning → the entire feature becomes dead code; the feature flag and clean provider abstraction are the exit ramp.

Ramp-up. Low for the recommended path: a mid-level Laravel engineer familiar with Socialite can ship a tested custom provider in 2–4 days, plus a day for account linking and token encryption. Ramp-up on the Symfony bundle itself is negative value — learning Symfony's security firewall internals to port code we will then rewrite is wasted effort. Budget the time into the spike and credential acquisition instead, since obtaining a working api_key/api_secret and confirming the Connect service is still supported will likely dominate the timeline.