- Can I use sllh/hybridauth-bundle in a Laravel application?
- No. sllh/hybridauth-bundle is a Symfony bundle built around Symfony's Bundle class, DI extension, and service configuration, not a Laravel package. Using it in Laravel would mean hand-registering Symfony-style services and reconciling HybridAuth's session model with Laravel middleware. For Laravel, use Laravel Socialite instead.
- What is the Laravel equivalent of this package?
- Laravel Socialite is the framework-native analogue: it is first-party, maintained, session-integrated, and covers common OAuth providers. It gives you redirect and callback flows without a Symfony bundle layer. If you need more providers or OIDC features, evaluate Socialite providers or a managed identity provider.
- Which Symfony versions does sllh/hybridauth-bundle support?
- The bundle targets legacy Symfony 2.x and early 3.x era projects, with Symfony bundle and DI conventions from that period. Modern Symfony 5, 6, and 7 applications will likely need a fork or significant wiring changes. Treat it as a frozen dependency for a legacy Symfony estate, not a new-build choice.
- Is sllh/hybridauth-bundle maintained and safe for production authentication?
- Risk is high: the repository has low adoption signals such as roughly 25 stars and zero dependents, so defects are unlikely to be surfaced or patched by a community. It wraps HybridAuth 2.x, which is end-of-life upstream, while OAuth endpoints, scopes, PKCE, and OIDC requirements keep changing. Authentication is security-critical, so a low-adoption EOL wrapper is a compliance and incident-response liability.
- Which social providers does this bundle support?
- It integrates HybridAuth 2.x, which supports OAuth1 and OAuth2 providers such as Facebook, Google, and Twitter, plus others HybridAuth configured. Provider support is only as current as the underlying HybridAuth 2.x adapter and its endpoints. Before relying on any provider, verify current scopes, callback URL rules, and whether the provider now requires OIDC or PKCE.
- How is sllh/hybridauth-bundle configured in a Symfony app?
- Configuration follows the typical Symfony bundle pattern: register the bundle, enable it in the kernel for the target environment, and define providers with values like client_id, client_secret, scope, and callback route. The bundle's DI extension and Configuration class define the provider shape. Because this is a legacy bundle, confirm the exact service IDs and routing against the version you have installed.
- What should Symfony teams use instead of this bundle?
- For modern Symfony, evaluate knpuniversity/oauth2-client-bundle with league/oauth2-client, or HWIOAuthBundle if it matches your provider needs. Both are better positioned to track current Symfony and PHP releases. If you want identity handled outside the app, consider a managed IdP such as Auth0, Cognito, Keycloak, or Entra.
- Can sllh/hybridauth-bundle handle account linking or token refresh?
- The bundle is a Symfony integration layer over HybridAuth 2.x, so capabilities depend on what HybridAuth exposes for the provider adapter and flow. Login-only is the common use case; account linking and refresh-token handling require explicit design and provider-specific checks. For a new build, choose a library or IdP whose account-linking and token lifecycle model you can test directly.
- How do I migrate away from sllh/hybridauth-bundle without breaking login?
- Do not rip it out mid-quarter. Inventory providers and call sites, introduce a small SocialAuthProvider interface covering redirect, callback, profile, and token, implement it behind the current bundle, and add contract tests for each provider callback round-trip. Then swap the implementation to league/oauth2-client, Socialite, or a managed IdP without touching domain code.
- Does this package work with PHP 8 and modern Symfony, and how should I test it?
- Expect friction on PHP constraints, Symfony DI schema changes, PSR container differences, and HybridAuth 2's session assumptions, so PHP 8 and Symfony 5/6/7 support is not assumed. If you must keep it, freeze the dependency and add tests that exercise the full redirect and callback round-trip against each provider in a staging app. Revalidate provider endpoints, scopes, and callback registrations on a schedule because works-today compatibility is time-limited.