Connect Bundle Laravel Package

Getting Started

First, a reality check. symfonycorp/connect-bundle is a Symfony bundle — not a Laravel package. There is no ServiceProvider, no facade, no publishable config, and no composer.json extra.laravel block. Running composer require symfonycorp/connect-bundle inside a modern Laravel app will almost certainly fail dependency resolution: the 2019 release targets Symfony 3.4/4.x-era symfony/http-kernel, symfony/security, and symfony/dependency-injection. Laravel 9+ ships against Symfony 6, so Composer will either refuse or downgrade a pile of framework packages you don't want touched.

So "getting started" for a Laravel developer means deciding which layer you actually need:

1. Read the bundle source in this order — src/ConnectBundle.php (see what it registers), src/DependencyInjection/Configuration.php (the exact symfony_corp_connect config keys), and src/DependencyInjection/ConnectExtension.php (how the Api service is constructed). Ten minutes of reading tells you the whole contract.
2. Then look at the sibling library symfonycorp/connect. This is the actual OAuth client. The bundle is a thin DI wrapper around it. If you're in Laravel you want that class, or nothing at all.
3. Cheapest viable path in Laravel: don't install the bundle. Use Laravel Socialite with a custom driver pointed at https://connect.symfony.com/oauth/v2/auth and the token endpoint. You get session/state handling, redirect flow, and Socialite::driver(...)->user() for free.
4. If you insist on the upstream client: SymfonyCorp\Connect\Api is constructible standalone — new Api($clientId, $clientSecret, $redirectUri, $guzzleClient). No container required. That is the only piece of this ecosystem worth importing into a Laravel app.

First use case worth building: register an OAuth app on Symfony Connect, capture client_id / client_secret / redirect URI, then a two-route flow (/auth/redirect, /auth/callback) that resolves a users row by the returned Symfony Connect user id.

Implementation Patterns

Pattern 1 — Socialite custom provider (recommended). Extend Laravel\Socialite\Two\AbstractProvider, implement getAuthUrl, getTokenUrl, getUserByToken, and map the profile response to id, nickname, name, email, avatar. Register it in a service provider via Socialite::extend('symfonyconnect', fn () => ...). This is the only pattern that stays idiomatic Laravel and survives the package being archived.

Pattern 2 — Standalone symfonycorp/connect client. Use new Api(...) inside a small SymfonyConnectService bound as a singleton. Expose redirectUrl() (wraps getAuthorizationUrl()) and handleCallback(string $code) (wraps getAccessToken() and returns the User value object). Keeps the vendor dependency isolated to one class so you can swap it for a generic OAuth client later.

Pattern 3 — Controller/flow shape. GET /auth/symfony/redirect builds the authorize URL with a state value stashed in the session; GET /auth/symfony/callback verifies state, exchanges the code, then User::updateOrCreate(['symfony_connect_id' => $remote->getId()], [...]). Always store the remote id in its own indexed column — never key off email, since Connect accounts can change it.

Pattern 4 — Legacy Symfony co-existence. If you're maintaining a Symfony app and a Laravel app, the bundle is fine on the Symfony side. Enable it in config/bundles.php, configure under symfony_corp_connect in YAML, and wire the provided security factory/provider/listener into security.yaml. Consume the resulting identity in Laravel by issuing your own signed token or sharing a session store — do not attempt to share Symfony's session cookie.

Pattern 5 — Testing. The client is Guzzle-based, so Http::fake() will not intercept it. Either inject a GuzzleHttp\Handler\MockHandler into your service, or (cleaner) bind a fake implementation of your own SymfonyConnectService interface and never touch HTTP in feature tests. Assert the state-mismatch branch explicitly — it's the one that gets skipped and then breaks in production.

Pattern 6 — Token persistence. If you need to call Connect profile APIs after login, persist the access token on the user row and refresh via a queued job rather than inline in the callback.

Gotchas and Tips

• Archived since 2019. No security patches, no PHP 8.1+ guarantees, no Symfony 6 support. Treat every line as frozen legacy code. Do not build a new auth path on it without a migration plan.
• The identity service itself is legacy. Symfony Connect was de-emphasised by the Symfony project — verify connect.symfony.com is still live and issuing tokens for your use case before writing code. If your real need is "log in with an account," standard OIDC via Socialite is safer.
• Composer conflicts are the first failure mode, not runtime bugs. If composer require tries to downgrade symfony/* or laravel/framework, stop — you're about to break the app. Use --dry-run first.
• No Laravel config publishing. The config keys live in the bundle's Configuration.php (something like app_id / app_secret / callback URI). Don't guess from blog posts; read the file. A single mismatched key silently produces a null client.
• Redirect URI must match byte-for-byte what you registered at Connect, including trailing slash and scheme. Connect does not do fuzzy matching, and the error surfaces as a generic OAuth failure, not a helpful message.
• State handling differs by path. The bundle's Symfony provider stores state in the Symfony session; Socialite stores it in the Laravel session. Never mix the two in one flow — you'll get "invalid state" with no clue why.
• Debugging: attach a Guzzle Middleware::log() to the injected client. The client throws on non-2xx and the exception message is thin; log getResponse()->getBody() yourself to see Connect's actual error payload.
• The clean extension point is the injected Guzzle client. Retry, caching, and logging middleware all belong there. This is also the seam that survives if you later drop the bundle and keep the library.
• Don't expose the vendor exception to users. Catch broadly at the controller boundary, log the detail, redirect back to login with a generic message. Raw OAuth exception text leaks client ids in some flows.
• If you inherit this in a Symfony app: pin PHP and Symfony versions in composer.json, write a test around the callback controller, and schedule replacement with a generic OAuth2/OIDC client. There is no upstream to fix anything you find.