oauth2-client: the base package, with every actual provider living somewhere else

The providers are other packages, not this repository

The most common misreading of this project is that it contains provider integrations. It does not. What ships here is a base, and the page makes the split explicit: there are official PHP League provider clients and third-party provider clients, both listed on the documentation site rather than in this repository, with Facebook, GitHub, Google, Instagram, and LinkedIn named as examples of what exists elsewhere. What this package provides out of the box is a single class, `GenericProvider`, which connects to any service provider using bearer tokens as defined in the OAuth 2.0 Bearer Token spec. So the realistic shape of a project using it is two dependencies: this base plus one provider package, and for an unlisted provider, a class of your own written against the guide for implementing a provider client. The page invites that last case directly, saying that if your provider is not in the list you can add it.

It removes RFC 6749 mechanics, not provider quirks

The stated purpose is to keep the concerns of RFC 6749 out of your application, and the framing is that the login flow seen around the web as a connect-with-Facebook button is a common integration that can be tricky and tedious to do right. The library is described as working with any OAuth 2.0 provider that conforms to the Authorization Framework, which is the actual scope boundary. Above that baseline, most real providers add behaviour the specification does not describe, and that is where this base stops: the page says you may extend and wrap the library to support additional behaviour. That distinction is the practical one. RFC mechanics such as the authorization request, the token exchange, and the refresh are the base's job, while provider-specific scope names, non-standard endpoints, and idiosyncratic token responses belong in the provider layer above it. Treating the base as if it handled everything is what produces the code that works for one provider and breaks for the next.

Four PSR compliance claims and a request to patch oversights

Standards compliance is stated as a list of four: PSR-1 for basic coding standards, PSR-2 for code style, PSR-4 for the autoloader, and PSR-7 for HTTP messages. Each links to its accepted specification document in the PHP-FIG repository. PSR-7 is the one with practical consequences rather than cosmetic ones, since it means the HTTP messages exchanged during the token exchange and any refresh are objects of a shared interface rather than a bespoke response type, so a PSR-7 implementation elsewhere in your stack can be composed with it. The page also treats compliance as an open issue rather than a settled claim, saying that if you notice compliance oversights you should send a patch via pull request. That is a useful signal about how the project treats its own guarantees, and it is also where the project's PHP-FIG roots are visible in a repository tree that otherwise contains only `src/`, `test/`, `docs/`, and configuration files.

PHP 7.1 through 8.5, a floor rather than a target

The supported versions are listed newest first, and the list is the longest part of the README: PHP 8.5, 8.4, 8.3, 8.2, 8.1, 8.0, then 7.4, 7.3, 7.2, and 7.1. Ten minor lines, spanning seven years. Read it as a compatibility floor rather than a testing matrix. What it guarantees is that the package will not refuse to install on an older runtime, and it implies the code carries no syntax above PHP 7.1 and avoids features whose availability moved between those versions. What it does not tell you is which of those combinations the test suite runs against on each change, and the page does not say. If you are on an old line the practical question is whether anyone is still fixing things, and the honest answer comes from the release dates rather than the list: the newest tag is 2.9.1 from 2026-09-16, preceded by 2.9.0 from 2025-11-25 and 2.8.1 from 2025-02-26. That gap of about ten months between 2.9.0 and 2.9.1 says more about current activity than the version list does.

Usage documentation lives on a separate site, and the tree says so

Almost nothing about how to use this package is in the repository. The usage section consists of a single sentence pointing at a basic usage guide hosted on the documentation site, and the same is true of the provider lists and the implementing-a-provider guide. The README ends at licence and standards, which is why it can be read in under a minute. What the tree does tell you is that there is more under the hood than the README mentions: a `docs/` directory, a `test/` directory alongside a `phpunit.xml.dist`, a `CHANGELOG.md`, a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md`, and a `CREDITS.md`. That last one is unusual in a package of this kind and worth knowing about if you are assessing the project's history, since it implies the maintainers track contributions separately from the git log. There is also a `composer.json` at the root, which is the only place the package name and its dependencies are defined.

MIT licensing with no caveats in the tree

The licensing is the simplest part. The README states the MIT License and points at a `LICENSE` file in the repository, and a `LICENSE` file is indeed present at the root. There is no dual licensing arrangement, no exceptions carved out for vendored code, and no separate licence for the documentation, so if you are reading this because you need to confirm obligations before shipping, the answer is that there is nothing further to check on this page. The badges at the top point at the continuous integration workflow, code coverage, the gitter chat room, the releases page, and the Packagist package listing, which is the distribution channel for a package of this kind. Note that the package name used on Packagist and in code is `league/oauth2-client`, which differs from the repository name, since the repository lives under the organisation rather than the package namespace.

Editorial conclusion

Take oauth2-client if you are writing a PHP integration against an OAuth 2.0 provider and want the RFC 6749 mechanics handled without hand-rolling the flow, particularly if the provider uses bearer tokens and you can start from GenericProvider. Check three things before you plan around it. This repository is the base only; Facebook, GitHub, Google, Instagram, and LinkedIn support all come from separate official or third-party packages, so budget for a second dependency. The supported version range is unusually wide, from PHP 7.1 to 8.5, which tells you the floor rather than what it is tested against. And the documentation that would answer most of your questions is not in the repository, since usage examples, provider lists, and the guide for implementing a provider all live on a separate documentation site.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thephpleague/oauth2-client on GitHub