# league/oauth2-server: a spec-compliant OAuth 2.0 authorization server for PHP > league/oauth2-server is a PHP library that implements the OAuth 2.0 authorization server role, not a ready-made service. It is for PHP teams that need to issue and validate access tokens from their own code, and who accept wiring storage and HTTP layers themselves. **thephpleague/oauth2-server** — A spec compliant, secure by default PHP OAuth 2.0 Server - Repository: https://github.com/thephpleague/oauth2-server - Website: https://oauth2.thephpleague.com - Stars: 6,668 · Forks: 1,134 - Language: PHP - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/thephpleague-oauth2-server ## What league/oauth2-server actually is, and who it is for The README describes league/oauth2-server as a standards compliant implementation of an OAuth 2.0 authorization server written in PHP. The phrase that matters is authorization server. If you are building a PHP API and want it to hand out access tokens, validate them on incoming requests, and let clients refresh them, this library covers that role. It does not give you a user database, a login screen, or a running process. The README says you can configure an OAuth 2.0 server to protect your API with access tokens, or allow clients to request new access tokens and refresh them. Everything between those two sentences is your application code. The intended audience is therefore a PHP team with an existing user store and an existing HTTP stack, not someone who wants to stand up an identity provider this afternoon. The README also lists community integrations for Drupal, Laravel Passport, CakePHP, Mezzio, Symfony and CodeIgniter 4, which is a fair signal of where the library expects to be embedded. ## The grants and RFCs the library implements Six grants are supported out of the box according to the README: authorization code, client credentials, device authorization, implicit, refresh, and resource owner password credentials. Five RFCs are listed as implemented: RFC6749 for OAuth 2.0 itself, RFC6750 for bearer token usage, RFC7519 for JSON Web Token, RFC7636 for Proof Key for Code Exchange, and RFC8628 for the device authorization grant. Two of those choices are worth flagging. The implicit grant and the resource owner password credentials grant are both in the specification but are widely treated as legacy; the README lists them without recommending them, and a new deployment has little reason to enable either. PKCE support matters more for anything with a public client, because RFC7636 is the mechanism that stops an intercepted authorization code from being replayed. The device authorization grant covers televisions, CLI tools and other inputs where typing a password is impractical. Bearer token usage and JWT support mean the library can produce tokens that other services validate without calling back into your server. ## Installation and a first authorization code flow The README gives one install command. The package name is league/oauth2-server and it comes from Packagist, so Composer is the only tool required. ```bash composer require league/oauth2-server ``` Requirements are stated plainly: the latest version supports PHP 8.2, 8.3, 8.4 and 8.5, and the openssl and json extensions are also required. Check both before you start, because a missing openssl extension fails at token signing time rather than at install time. The README also states that all HTTP messages passed to the server should be PSR-7 compliant, which is what lets the library sit behind Slim, Mezzio, Symfony or a plain PSR-7 implementation without knowing which one you use. The repository ships an examples directory with its own composer.json and a public entry point, so the fastest way to see the intended wiring is to read those files rather than guess. The library's own test command is the PHPUnit binary from the vendor directory. ```bash vendor/bin/phpunit ``` Running that after install confirms the package and its test dependencies are in place. Beyond this, the README does not document the wiring of storage adapters, repositories or the authorization endpoint; it points to the documentation site at oauth2.thephpleague.com for that, so the concrete first use lives there rather than in the repository. ## Where the library stops and your code begins This is the part that surprises people. league/oauth2-server implements the protocol, not the storage. The README does not describe a database schema, a migration, a default user provider or a token table. You supply the repositories that read clients, scopes, access tokens and refresh tokens, and you supply the PSR-7 request and response objects. That division is deliberate and it is the reason the library works inside so many frameworks, but it also means the security of your deployment depends on code the library never sees. A token repository that stores raw tokens instead of hashes, or a scope repository that returns every scope regardless of what the client requested, will produce a working OAuth flow with a broken security model. The library will not warn you. Treat the repository interfaces as the real attack surface and write tests against them, not just against the happy path of a token request. ## Limitations and cases where this is the wrong tool If you want an OAuth server you can start with Docker and administer through a web console, this is not it. There is no container image, no admin interface and no persistence layer in the README. Everything the library does is invoked from PHP code you wrote. The same applies if your stack is not PHP: the RELATED searches show people looking for OAuth servers in Node, Go, Python and Spring Boot, and league/oauth2-server answers none of those. A second limitation is upgrade exposure. The README requires PHP 8.2 or newer, so an application still on PHP 7.x cannot use the current release at all, and a team that upgrades PHP on a different schedule from its OAuth library will feel that constraint. Third, the README does not document token revocation, key rotation or rollback procedures. Those may exist in the documentation site, but the repository's own README is silent, and a team that needs rotation semantics should confirm them before committing to the library rather than after. ## How this differs from a framework bundle or a standalone identity service The clearest alternative named in the README is Laravel Passport, listed under community integrations. The difference in approach is one of scope. league/oauth2-server gives you the protocol implementation and expects you to assemble the rest; Passport wraps that same protocol work in Laravel conventions, so migrations, an Eloquent client model and the routes come with the framework. If your application is Laravel, Passport saves you the assembly. If it is not, Passport is irrelevant and the underlying library is what you want. The Symfony bundle listed in the same section plays the equivalent role for Symfony. The other alternative is a standalone authorization service that runs as its own process and speaks OAuth to your PHP application over HTTP. That trades the library's flexibility for operational separation: you get a service you can deploy and monitor independently, but you also get a second system to run, and your application stops owning its own token issuance. Neither approach is universally better; the deciding question is whether token issuance belongs inside the application that consumes it. ## Maintenance, licence and what to check before adopting The repository is not archived, and the last push was on 2026-06-25, which is the same date as the 9.4.1 release. The two preceding releases were 9.4.0 on 2026-06-14 and 9.3.0 on 2025-11-25, so the cadence is patch and minor work rather than constant churn. The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is a summary of the licence identifier, not legal advice, and you should read the bundled LICENSE file for the actual terms. The README notes that the library received funding from the Mozilla Secure Open Source Fund for a security audit, and that security issues should be emailed to a named address rather than filed in the issue tracker. Before adopting, check three things: your PHP version against the 8.2 to 8.5 range, the presence of the openssl and json extensions, and whether your HTTP layer really produces PSR-7 messages. If any of those fails, the library is not the problem to solve first. ## Conclusion Adopt league/oauth2-server if you are building a PHP API and need the authorization server role inside your own application, with your own user table and your own PSR-7 stack. Do not adopt it if you want a running identity service with an admin UI and persistence out of the box; this is a library, and the README points you at framework bundles such as Laravel Passport when you want that. Before writing code, confirm your PHP version matches 8.2 through 8.5, that openssl and json are enabled, and that your HTTP layer produces PSR-7 messages, because the library assumes all three. ## FAQ ### What is league/oauth2-server? It is a standards compliant implementation of an OAuth 2.0 authorization server written in PHP, distributed as the league/oauth2-server package on Packagist. It implements the protocol and the grants, and leaves storage and HTTP handling to your application. ### How do I install league/oauth2-server? Install it with Composer using the command composer require league/oauth2-server. The latest version requires PHP 8.2, 8.3, 8.4 or 8.5, plus the openssl and json extensions. ### How do I implement an OAuth 2.0 server with league/oauth2-server? The README does not walk through the implementation. It states that HTTP messages passed to the server should be PSR-7 compliant and directs readers to the documentation at oauth2.thephpleague.com, with an examples directory in the repository showing the wiring. ### What is an OAuth 2.0 authorization server? It is the component that issues access tokens to clients and validates them on protected requests. league/oauth2-server fills that role inside a PHP application, supporting the authorization code, client credentials, device authorization, implicit, refresh and password grants. ## Sources - [License: MIT](https://github.com/thephpleague/oauth2-server/blob/master/LICENSE) - [Project website](https://oauth2.thephpleague.com) - [README](https://github.com/thephpleague/oauth2-server/blob/master/README.md) - [Releases](https://github.com/thephpleague/oauth2-server/releases) - [thephpleague/oauth2-server on GitHub](https://github.com/thephpleague/oauth2-server) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thephpleague-oauth2-server