Oauth Server Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication/authorization. This package sits at the "build" end of the spectrum: it's a self-hosted OAuth 2.0 authorization server for Symfony. The decision it informs is whether to own the token-issuing surface (grants, scopes, refresh tokens, client registration) or delegate to a managed IdP (Auth0, Cognito, Keycloak, Okta). The answer is almost always "delegate" unless you have regulatory or data-residency constraints forcing self-hosting.
• Framework-ecosystem fit. Despite being catalogued as a "Laravel/PHP package," this is a Symfony 5 bundle, not Laravel. It cannot be dropped into a Laravel app. If your roadmap is Laravel, the correct reference points are Laravel Passport (full OAuth2 server) or Sanctum (first-party SPA/mobile tokens). This package is a non-candidate for that stack.
• Legacy maintenance vs. migration. The signal here — 2 stars, 0 dependents, last release March 2022, an upstream lineage (FOSOAuthServerBundle) that has been effectively deprecated in favor of league/oauth2-server integrations — argues for a roadmap item to migrate off, not a roadmap item to adopt. A PM should treat this as a trigger to schedule an auth-layer modernization spike.
• Vendor/dependency risk scoring. Use it as a worked example in your dependency-review policy: low stars, zero dependents, and a stale release date are all "do not adopt" flags. This is the kind of package that becomes a security liability the moment an OAuth-related CVE lands and no one is patching.
• Feature scoping for auth. If the product needs OIDC, PKCE, OAuth 2.1, token introspection, or dynamic client registration, this package's feature surface (Symfony 5-era OAuth 2.0 server) will not cover it. That constrains what you can promise in a security questionnaire or enterprise RFP.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony 5, not Laravel and not a newer Symfony major.
• You already depend on FOSOAuthServerBundle and are pinned to its data model, and you need a fork that keeps the lights on for a short, time-boxed window.
• You have read and accepted the diff against upstream (this is a fork, so "what did NovoSGA change?" is a mandatory review, not a formality).
• You have a concrete migration date to a maintained alternative and are not adding new scope to the legacy auth layer.

Look elsewhere when:

• Your stack is Laravel — hard stop. Use Passport or Sanctum.
• The project is new. Building on a 2-star, zero-dependent, last-released-in-2022 bundle is a bet against your own maintenance budget. Use league/oauth2-server directly, the maintained Symfony League OAuth2 bundle, or a managed IdP.
• You need active security patching. OAuth and JWT libraries are high-value CVE targets; an unmaintained server is an unpatched attack surface.
• You need modern protocol coverage. OAuth 2.1, OIDC, PKCE-first public clients, token revocation/introspection — plan for a dependency that ships these, which this does not.
• You need a support contract or SLA. There is no commercial backing here.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated novosga/oauth-server-bundle as an option for our authentication layer and are recommending we do not adopt it. It is an unmaintained Symfony 5 fork of a deprecated upstream library, with negligible community traction (2 stars, no known dependents) and no release since March 2022. In an area as security-sensitive as login and token issuance, an unpatched dependency is a liability, not a savings. The cheaper and safer path is either a managed identity provider or a well-maintained library — and if we currently run the upstream FOSOAuthServerBundle, we should fund a migration rather than a fork.

To engineering (the ask): Two things. First, confirm whether any service still depends on FOSOAuthServerBundle or this fork; if so, we need a migration plan with a date, because it is receiving no upstream fixes. Second, for any new auth work, standardize on league/oauth2-server (or the maintained Symfony integration) for self-hosted needs, and Laravel Passport/Sanctum where the stack is Laravel. Treat the "no release in 24+ months, no dependents" pattern as a hard gate in our dependency-review checklist going forward.

Framing to avoid: don't present this as "a free OAuth server we could use." Present it as a fork of a deprecated project with no maintenance signal — the cost isn't the license, it's the eventual emergency migration under time pressure, plus the security exposure in the interim.