- Is league/oauth2-client a Laravel package?
- No. It is a framework-agnostic PHP library implementing the client side of RFC 6749, and it ships no service provider, facade, config file, migration, or Blade views. In a Laravel app it belongs in the integration or adapter layer, wrapped by your own service classes rather than called directly from controllers or domain code.
- How do I install league/oauth2-client in a Laravel application?
- Run composer require league/oauth2-client. There is no publish step, no config file, and no service provider to register. The only dependency of note is Guzzle, which every modern Laravel app already has, so the effective dependency weight is neutral. Most teams bind a small ProviderFactory or OAuthClientManager singleton in their own service provider to keep client construction testable.
- Should I use league/oauth2-client or Laravel Socialite for social login?
- For end-user login with Google, GitHub, or similar, use Laravel Socialite. Socialite already covers the login flow, and much of the ecosystem's provider glue, including SocialiteProviders, is itself built on top of league/oauth2-client. Reach for league/oauth2-client directly when the requirement is third-party API authorization, such as connecting to a customer's Google, Microsoft, or Salesforce account to sync data, or machine-to-machine client-credentials flows.
- How do I get an access token with GenericProvider in Laravel?
- Construct a GenericProvider with the client ID, client secret, token URL, and authorization URL, then call getAccessToken with the grant type you need, such as authorization_code or client_credentials. For refreshes, the library exposes refresh-token setting via SettableRefreshTokenInterface since 2.8.0, so you can call setRefreshToken before requesting a new access token. Persisting, encrypting, and scheduling those tokens is your application's responsibility, not the library's.
- Does league/oauth2-client support PKCE and refresh tokens?
- Yes. PKCE, per RFC 7636, is supported since version 2.7.0, and refresh-token setting landed in 2.8.0 through SettableRefreshTokenInterface. These two additions clear the security and UX requirements most commonly raised by security review. You still own the lifecycle: generating and storing the verifier, rotating refresh tokens, and handling races between concurrent refresh attempts.
- What does league/oauth2-client not handle for me?
- Token storage and encryption at rest, refresh scheduling, CSRF state generation and validation, PKCE verifier persistence, multi-tenant credential isolation, audit logging, and keeping secrets out of logs are all your code. The library deliberately stays thin and provides primitives such as getState and setState without enforcing a safe composition. Plan for those concerns explicitly in your adapter layer rather than assuming the package handles them.
- Which Laravel and PHP versions work with league/oauth2-client?
- The library imposes no Laravel version constraint because it does not depend on the framework, so current Laravel releases are fine. It requires a PHP version supported by the 2.x line, which is certified through PHP 8.5, and version 2.8.0 raised the Guzzle floor to 6.5.8 or 7.4.5 because of known vulnerabilities in earlier releases. If any legacy service in your stack is pinned to an older Guzzle, upgrade it first; that is a real, checkable precondition.
- How do I test an OAuth 2.0 integration without hitting the provider?
- Call getHttpClient on your provider subclass and inject a Guzzle client built with a MockHandler and your queued responses. That keeps tests fast and hermetic and lets you assert on the exact request body, headers, and grant parameters sent to the token endpoint. Wrap this in your own adapter tests so each provider subclass has coverage for its error bodies and token response quirks. Also test your token storage and refresh logic separately from the HTTP layer.
- What errors and edge cases are common with non-standard providers?
- Non-JSON or non-conformant access-token responses throw UnexpectedValueException, and token expiry typing has been patched repeatedly, for example when expires is not numeric or expires_in is 0. Each provider you integrate should get its own subclass with its own tests rather than relying on GenericProvider behavior. Static analysis can also flag changes on minor upgrades, since 2.8.0 altered the prepareAccessTokenResponse docblock type hint, which is explicitly noted as potentially affecting downstream providers.
- Is league/oauth2-client well maintained, and what are the alternatives?
- The 2.x line has run since 2017 with semver-respecting, mostly additive releases, per-PHP-version CI certification, and a strong backwards-compatibility record. The residual risk is not breakage on minor upgrades but a future 3.0 that requires migrating your provider subclasses. Alternatives include Laravel Socialite for login flows, SocialiteProviders for ready-made provider glue, and dedicated SDKs from vendors whose APIs drift far from the spec.