- Can I install jdelaune/oauth2-client-bundle in a Laravel application?
- No, not as a working integration. It is a Symfony bundle built around a Bundle class, a DependencyInjection extension with a Configuration tree, and compiler passes, none of which Laravel's bootstrap lifecycle or container understands. Composer may resolve the dependency, but no service provider registers the clients, so nothing ends up in your container. Treat it as reference material and rewrite the glue as a Laravel service provider.
- Is jdelaune/oauth2-client-bundle still maintained?
- Effectively no. The last release was 2019-12-17, the declared Symfony 2 to 4 support envelope is entirely end of life, and the repository shows 5 stars with 0 dependents. With no downstream usage there is no regression surfacing and no security response channel, so a vulnerability in the wrapper would go unpatched. MIT licensing at least makes forking or copying the pattern legally clean.
- What is the Laravel equivalent of this Symfony OAuth2 bundle?
- It depends on the requirement. If you need social or external identity provider login, Laravel Socialite is the idiomatic answer and covers Google, GitHub, Azure, and others out of the box. If you need to call third-party APIs on behalf of a user with token refresh, use league/oauth2-client directly plus the provider-specific packages such as league/oauth2-google or thenetworg/oauth2-azure. Those libraries are framework agnostic, actively maintained, and are the actual substance under this wrapper.
- Which Symfony and PHP versions does this bundle support?
- The package is a 2019-era artifact targeting Symfony 2 through 4, and Symfony 4 reached end of life in November 2023. PHP 8.x compatibility is unverified: typed properties, dynamic property deprecations, and return type changes in the Symfony components it touches are plausible failure points. Its composer.json constraints will likely block resolution against a modern application's dependency graph without forking and patching.
- How do I configure multiple OAuth2 providers with this bundle?
- The bundle exposes a Configuration tree where you declare each provider by name along with its credentials and scopes, and the extension wires one autowired client service per provider entry. The idea worth copying is a client factory keyed by provider name plus a registry binding, so consumers ask for the provider they need instead of constructing clients. In Laravel that collapses into a single config file, a singleton factory binding, and a small resolver class, roughly 100 to 200 lines.
- How do I refresh access tokens or handle refresh token rotation?
- The bundle only wires and configures clients; token refresh itself comes from the underlying league provider through the standard grant objects. Persistence is entirely your responsibility: the bundle does not ship a token repository or storage strategy. You need to decide whether tokens live in the session, in encrypted per-user columns, or in an external secret store, and you need an explicit revocation and rotation story before going to production.
- How do I test or mock the OAuth2 clients in a Symfony application?
- Because the bundle exposes clients as autowired services, the usual approach is to inject the client interface rather than the concrete class and substitute a fake through the test container. Assertions then focus on your own callback controller and token handling logic, not on the client internals. If you rewrite the pattern in Laravel, a container binding plus Http::fake() gives you the same isolation with less ceremony.
- Is this package safe to use in production?
- The risk here is provenance rather than line count. The wrapper is small but unmaintained, has zero dependents to surface regressions, ships no security response channel, and declares only end-of-life Symfony versions. If you must reuse it, fork it under the MIT license, pin the league provider packages to minor versions, and set a review cadence for that dependency chain. Vendoring it as a live dependency is hard to justify.
- How much work is it to move this pattern into a Laravel app?
- Realistically two to four engineering days including tests, assuming the league provider packages already cover your target identity providers. The work is a config/oauth2.php file, a singleton client factory binding, a provider resolver, a callback controller, and a token repository. That is reimplementation, not integration, because none of the bundle's Symfony DI machinery transfers. The client factory and registry pattern are what you are actually porting.
- Which OAuth2 grants does this bundle support for third-party API access?
- Grant support is inherited from league/oauth2-client, so authorization code, client credentials, and refresh token flows depend on the provider package you add rather than on the bundle. Authorization Code with PKCE is the common case for user-delegated API access, while client credentials covers machine-to-machine calls. Decide up front which grants and which providers you need, because that determines whether a multi-provider registry abstraction is even warranted or a single config entry is enough.