# thephpleague/oauth2-client: a PHP base for OAuth 2.0 provider integrations > The league/oauth2-client package gives PHP applications a provider-agnostic base for the OAuth 2.0 authorization code flow, the client credentials grant, and Bearer-token APIs. This review covers what it abstracts, where it stops, and who should pick it over a provider's own SDK. **thephpleague/oauth2-client** — Easy integration with OAuth 2.0 service providers. - Repository: https://github.com/thephpleague/oauth2-client - Website: http://oauth2-client.thephpleague.com - Stars: 3,819 · Forks: 769 - Language: PHP - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/thephpleague-oauth2-client ## The problem league/oauth2-client solves for PHP applications The README opens with the observation that the OAuth 2.0 login flow, the one behind "Connect with Facebook/Google/etc." buttons, is "tricky and tedious to do right." The package exists so that an application does not have to reimplement RFC 6749 each time it adds a provider. It is aimed at PHP developers who need to send a user to an authorization endpoint, receive a code, exchange that code for a token, and then call an API with that token, without hand-writing the redirect, state handling and token exchange per vendor. The library is deliberately narrow: it is a client, not an identity provider, and it does not decide anything about your application's sessions. That narrowness is the point. The README states the package "will work with any OAuth 2.0 provider that conforms to the OAuth 2.0 Authorization Framework," and that a GenericProvider is shipped for services using Bearer tokens. Anything beyond the specification, such as provider-specific profile endpoints, is left to extension or to a provider client built on top. ## How the provider abstraction and GenericProvider fit together The architecture is a small class hierarchy rather than a framework. GenericProvider is the concrete implementation for any service that follows the specification with Bearer tokens; provider clients for Facebook, GitHub, Google, Instagram and LinkedIn are listed separately as official or third-party packages, and they extend or wrap this base to add behavior the specification does not cover. That split matters when you evaluate the project: the base package handles the protocol mechanics, and the provider packages handle the parts that differ per vendor. The README points to an "Implementing a Provider Client" guide for anyone whose provider is not on either list, which is the escape hatch when a service deviates from the specification. Compliance with PSR-1, PSR-2, PSR-4 and PSR-7 is stated in the README, so the HTTP layer is PSR-7 rather than a bespoke request object, which is what lets you plug in a PSR-7 implementation of your choosing. The README does not describe the internal token storage or refresh flow in detail; for that it defers to the basic usage guide and the provider documentation. ## Installing league/oauth2-client and making a first authorization request The README does not print install commands; it links to the documentation site at oauth2-client.thephpleague.com for usage and code examples, and the repository carries a composer.json, so the package is distributed through Composer under the name league/oauth2-client. The README lists supported PHP versions from 7.1 through 8.5, so check your runtime before requiring it. ```bash composer require league/oauth2-client ``` After that, the documented path for a specification-conformant provider is to construct a GenericProvider with the provider's client id, client secret, redirect URI and endpoint URLs, then use it to build the authorization URL and later exchange the returned code. The README refers to the basic usage guide for these examples rather than inlining them, so treat the documentation site as the source for exact constructor arguments and method names. What you should see after the first step is a redirect to the provider's authorization page; after the user approves, the provider returns a code to your redirect URI, and the exchange turns that code into a token you can attach to API calls. The README does not document the exact method names for that exchange, so verify them against the usage guide before writing production code. ## Where the library stops and you have to write code The most common wrong expectation is that this package is a complete integration. It is not. The README is explicit that providers offer "additional functionality above and beyond the OAuth 2.0 specification," which is precisely why provider clients exist as separate packages. If your provider returns non-standard fields, uses a different token format, or requires extra parameters on the authorization request, GenericProvider alone will not cover it and you will be writing a provider client. The README also does not document token persistence, refresh scheduling, or rollback behavior, so decisions about where tokens live and when they are refreshed belong to your application, not to this package. There is no mention of a built-in HTTP client; the PSR-7 compliance means you supply that layer. For a single-provider integration where the vendor's own SDK already exposes the API calls you need, this base adds a layer without removing much work, and the vendor SDK is the shorter path. The package is also not an authorization server: if you need to issue tokens rather than consume them, this is the wrong tool entirely. ## Comparing the base package with a provider-specific SDK The real alternative for many teams is the provider's own SDK, for example a vendor-maintained client that bundles both the OAuth 2.0 flow and the API calls. The difference is where the abstraction sits. A vendor SDK optimizes for one provider: it knows that provider's endpoints, its non-standard parameters and its API surface, so a single dependency covers login and the subsequent calls. league/oauth2-client optimizes across providers: the flow is implemented once, and the provider-specific parts live in separate client packages or in code you write. If you integrate with three providers, the base package plus three provider clients keeps one flow implementation in your codebase. If you integrate with one, the vendor SDK removes a layer. The README's list of official and third-party provider clients is the deciding input here: check whether your provider already has a client before assuming you must build one. ## Maintenance, release cadence and the MIT licence The repository is not archived, and the last push was on 2026-09-16, the same day release 2.9.1 was published. Before that, 2.9.0 landed on 2025-11-25 and 2.8.1 on 2025-02-26, so the visible release rhythm is roughly one minor bump a year with patch releases in between. That is a slow cadence for a protocol library, which is defensible given that RFC 6749 has not changed, but it does mean new PHP versions may appear in the requirements list before a release that touches anything else. The supported PHP range in the README runs from 7.1 to 8.5, which is unusually wide and worth checking against your own minimum. The licence is MIT, which permits commercial and closed-source use; the README points to the LICENSE file for the full text, and the usual obligations around preserving the copyright notice apply. Nothing in the README describes a paid tier, a support contract or a deprecation policy, so upgrade planning rests on the CHANGELOG and the release notes. ## Conclusion Adopt thephpleague/oauth2-client if you are writing a PHP application that talks to several OAuth 2.0 providers and you want one flow implementation instead of a different vendor SDK per integration, and verify first that your provider's quirks are covered by an existing client on the official or third-party provider list. Skip it if you only ever talk to one provider whose own SDK already ships the API calls you need, because this package stops at the token and leaves those calls to you. ## FAQ ### What is an OAuth2 client? In this package's terms, it is the application-side component that sends a user to an authorization endpoint, receives a code, exchanges it for a token, and then calls an API with that token. The README describes league/oauth2-client as a base for exactly that role, implementing RFC 6749 without pulling the rest of your application into it. ### How do I create an OAuth client with league/oauth2-client? The README does not print the constructor call; it points to the basic usage guide on oauth2-client.thephpleague.com for examples using GenericProvider. The package itself is installed through Composer as league/oauth2-client, and GenericProvider is the documented starting point for any specification-conformant provider using Bearer tokens. ### Does league/oauth2-client work with any OAuth 2.0 provider? The README states it will work with any provider that conforms to the OAuth 2.0 Authorization Framework, and ships a GenericProvider for services using Bearer tokens. Providers that add behavior beyond the specification need a provider client, which is why official and third-party clients exist as separate packages. ### What PHP versions does league/oauth2-client support? The README lists PHP 7.1 through 8.5 as supported versions. Check that range against your runtime before requiring the package, since the supported list is wider than most libraries of this kind. ### Is league/oauth2-client a full integration for a specific provider? No. The README separates the base package from provider clients, and notes that providers offer functionality above and beyond the OAuth 2.0 specification. For provider-specific API calls and non-standard parameters you either use a provider client or implement one. ## Sources - [License: MIT](https://github.com/thephpleague/oauth2-client/blob/master/LICENSE) - [Project website](http://oauth2-client.thephpleague.com) - [README](https://github.com/thephpleague/oauth2-client/blob/master/README.md) - [Releases](https://github.com/thephpleague/oauth2-client/releases) - [thephpleague/oauth2-client on GitHub](https://github.com/thephpleague/oauth2-client) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thephpleague-oauth2-client