Oauth2 Server Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on identity infrastructure. This package sits in the "we own our authorization server" column. Choosing it (or its upstream lineage) is the decision to issue OAuth2 tokens from inside your own Symfony application rather than delegating to Auth0, Keycloak, FusionAuth, or Cognito. That's a strategic commitment to owning token issuance, key rotation, consent screens, and the security posture that comes with them.
• Opening your API to third parties. The core use case is turning a first-party Symfony app into an OAuth2 authorization server so external clients — partner integrations, customer-built dashboards, marketplace apps — can request scoped access on a user's behalf without sharing credentials. This unlocks platform/ecosystem roadmap items (public API program, app marketplace, embedded integrations) that are blocked while auth is session-cookie-only.
• Machine-to-machine and service-to-service auth. Client-credentials grants let internal services and customer backends call your API with scoped tokens. Useful for deciding whether to ship a "API keys" feature or a proper OAuth2 client registration flow — this package supports the latter.
• SSO across your own product surface. If you run multiple Symfony applications or are acquiring products, a shared authorization server simplifies consolidation. This informs roadmap sequencing: identity consolidation before, not after, a multi-product integration push.
• Feature-level scoping decisions. Because scopes are declared in configuration, the PM gets a concrete artifact for negotiating API surface with partners — "what can a third-party app actually do?" becomes an explicit, reviewable list rather than an implicit yes.
• Not a fit for: consumer social login (that's a client, not a server — use an OIDC client bundle), or teams without dedicated security engineering capacity.

When to Consider This Package

Consider it only under a narrow set of conditions:

• You are on Symfony (this is a bundle, not a framework-agnostic library) and want to stay inside the Symfony DI/security model rather than bolting on a standalone identity provider.
• You need a standards-compliant OAuth2 authorization server and have evaluated the canonical league/oauth2-server plus its maintained Symfony integration (trikoder/oauth2-bundle) — this package is a downstream fork of that lineage.
• You can vendor and patch it yourself. Treat it as source, not as a dependency.

Look elsewhere — strongly — if any of the following are true, and for most teams several will be:

• Zero stars, zero dependents, no release since December 2022. That is four years of no security maintenance on a component whose entire job is to be attacked. OAuth2 implementations accumulate CVEs; an unmaintained fork inherits them without patches.
• You need OpenID Connect, dynamic client registration, PKCE hardening, or token revocation handled for you. A 2022 snapshot will lag current spec guidance.
• You want vendor support or an SLA. There is none.
• Your team lacks someone who can read league/oauth2-server internals and audit grant flows.

Recommended default: use the maintained upstream (trikoder/oauth2-bundle / league/oauth2-server) directly, or buy a managed IdP. Adopt this fork only if it contains a specific patch you need and you are prepared to own it forever.

How to Pitch It (Stakeholders)

For executives: We have a build-vs-buy decision on identity. Standing up our own OAuth2 server unblocks revenue-relevant roadmap items — public API access, partner integrations, an app marketplace — that we cannot ship while authentication is session-only. This specific package is a Symfony-native implementation of that capability, MIT-licensed, no per-token or per-MAU cost. But it is effectively unmaintained (no release since 2022, no community, no dependents), so I am not recommending it as-is. My recommendation is the maintained upstream library it descends from, or a managed provider if we don't want to staff identity security. The buy option costs money per user but removes ongoing security burden; the build option costs engineering time and creates a permanent security-owned surface.

For engineering: This is a Symfony bundle wrapping league/oauth2-server, forked from trikoder/oauth2-bundle. It gives us authorization-code, client-credentials, and refresh-token grants with scopes declared in config. The tradeoff is explicit: it's a 2022 fork with no maintenance, so we'd be pinning and patching. I'd rather we take the upstream and contribute there, or take a managed IdP and spend our engineers on product. If there is a specific bug fix in this fork we need, let's isolate exactly what it is and see whether it's mergeable upstream first.

Ask: Approve a one-week spike to compare (a) upstream self-hosted, (b) managed IdP, on total cost including security ownership — before we commit to any third-party API roadmap dates that assume OAuth2 is solved.