- Is league/oauth2-server-bundle compatible with Laravel?
- No. league/oauth2-server-bundle is a Symfony bundle, so it plugs into Symfony's dependency injection, configuration tree and event system rather than Laravel's service container. Laravel applications should evaluate Laravel Passport first, since it wraps the same underlying league/oauth2-server library in a Laravel-native package. Only consider this bundle from Laravel if you are running a Symfony bridge or a hybrid stack where a Symfony kernel handles the OAuth2 endpoints.
- How do I install league/oauth2-server-bundle?
- Run composer require league/oauth2-server-bundle, then require doctrine/doctrine-bundle and doctrine/orm if you want the default Doctrine persistence layer. Add your client, grant type and scope definitions under config/packages/oauth2_server.yaml. The bundle ships a recipe-style config tree, so most setups need very little boilerplate beyond entity mapping and a security firewall entry.
- What does league/oauth2-server-bundle actually do?
- It integrates the league/oauth2-server library into a Symfony application and exposes a standards-compliant OAuth2 authorization server, including token, authorize and introspection endpoints. It handles the protocol plumbing (RFC 6749 flows, token issuing, scope validation) so you only implement client and user persistence. It is the maintained successor to trikoder/oauth2-bundle, built in coordination with trikoder and Symfony core team members.
- Which OAuth2 grant types does the bundle support?
- Out of the box it supports Authorization Code, Implicit (deprecated but retained for legacy clients), Resource Owner Password Credentials, Client Credentials and JWT Bearer Token grants. You can also register custom grant types when you have niche requirements. For public clients, enable PKCE in the authorization server config rather than relying on the Implicit grant, which is deprecated by RFC 6749.
- Does league/oauth2-server-bundle require Doctrine?
- Doctrine ORM is the default persistence layer and is what the quick start documentation recommends, so most projects install doctrine/doctrine-bundle and doctrine/orm. However, storage is adapter-based, so you can supply custom implementations for clients, access tokens, refresh tokens, auth codes and scopes backed by Redis, Elasticsearch or your own schema. That flexibility matters if you already have a non-Doctrine persistence stack.
- How risky is upgrading to league/oauth2-server-bundle v2.0?
- Treat v2.0.0 as an upgrade event rather than a drop-in patch. It removes the 1.x backward-compatibility layer and bumps required runtime dependencies, so any code that subclassed, decorated or extended v1 internals (services, event listener signatures, config node names, custom grant wiring) can break. Read the UPGRADE-2.x guide, run a static analysis pass with PHPStan or Psalm, and diff bin/console debug:config oauth2_server between v1 and v2 to enumerate config drift before touching production.
- Which PHP and Symfony versions does v2 of the bundle require?
- The dependency bump in v2.0.0 likely raises the minimum PHP and Symfony versions, but the exact constraints should be read from the v2 composer.json rather than from older v1 documentation, where the Symfony 6.4+ floor is no longer authoritative. Run composer why-not league/oauth2-server-bundle ^2.0 against your current platform to see precisely what blocks the upgrade. Because the bump can cascade into transitive Symfony and PHP upgrades, sequence the runtime upgrade before the library upgrade.
- Is this bundle a replacement for trikoder/oauth2-bundle?
- Yes. league/oauth2-server-bundle is the maintained replacement for trikoder/oauth2-bundle, created in coordination with trikoder and Symfony core team members to keep the integration in sync with Symfony releases. Migration usually means swapping the Composer requirement and re-validating your config and any custom service wiring. The 1.x branch remains in maintenance mode for bugfixes only, while active development happens on 2.x.
- How do I scale OAuth2 token storage for a high-throughput API?
- The default Doctrine storage writes tokens to a relational table, which can become a bottleneck under heavy token issuance or introspection load. Benchmark a Redis-backed or sharded storage adapter against your real traffic before committing to the Doctrine default at scale. Also consider token lifetimes and revocation strategy, since shorter-lived access tokens reduce storage pressure significantly.
- How do I test OAuth2 flows built with this bundle?
- Write functional tests that boot the Symfony kernel and exercise the token and authorize endpoints, for example with Symfony's KernelBrowser or an HTTP client in PHPUnit. Configure a test-only client, grant type and scope set in config/packages/test/oauth2_server.yaml so tests do not depend on production client secrets. Assert on token responses, error codes for invalid grants and scope enforcement rather than on internal service classes, which keeps your suite stable across minor upgrades.