Oauth Server Bundle Laravel Package

Product Decisions This Supports

• Almost none for a Laravel product — this is not a Laravel package. Despite the "Laravel/PHP" framing, gregoryeple/oauth-server-bundle is a fork of FOSOAuthServerBundle, a Symfony bundle. There is no service provider, no Laravel config publishing, no Eloquent integration. Any decision to adopt it in a Laravel codebase is a category error, so this evaluation mostly informs a rejection rather than a build/buy call.
• Legacy maintenance triage (the only real use case). The decision it can support is narrow: "we run an older Symfony application already wired to FOSOAuthServerBundle, we're blocked on a PHP/Symfony upgrade, and we need a patched fork to buy time." That's an exit-planning decision, not a roadmap decision.
• Roadmap input: OAuth2 provider capability is a real requirement, but this package doesn't satisfy it. If OAuth2/OIDC issuance is on your roadmap, the decision this package should trigger is "evaluate maintained alternatives" — Laravel Passport or league/oauth2-server directly for Laravel; trikoder/oauth2-bundle or League + Symfony's security stack for Symfony. FOSOAuthServerBundle itself has been effectively abandoned upstream, which is why forks like this exist.
• Build-vs-buy signal: buy, but not here. OAuth2 server implementation is exactly the kind of thing you should not hand-roll, so the buy instinct is correct — this specific artifact just fails the supplier-quality screen (0 stars, 0 dependents, single maintainer, last release June 2023, composite score 0).
• Risk-register entry, not a feature decision. The useful PM output is a documented "do not adopt" with reasoning, which prevents a future engineer from pulling it in because the name pattern-matches the need.

When to Consider This Package

Consider it only under all of the following:

• You already have a Symfony application running the original FOSOAuthServerBundle.
• You are blocked on a framework/PHP upgrade and need a fork with compatibility patches.
• You have done a line-by-line diff against upstream and confirmed the fork contains only the patches you want — the repo name (FOSOAuthServerBundle) and the package name (oauth-server-bundle) don't match, so verify what's actually in the tree before trusting it.
• You can pin the version, vendor or internally mirror it, and commit to a dated migration off it.

Look elsewhere if any of these are true:

• Your application is Laravel. Use Laravel Passport (full OAuth2 server), Sanctum (first-party SPA/token auth), or league/oauth2-server for custom flows. This bundle cannot serve you.
• You're on modern Symfony. Use trikoder/oauth2-bundle (League-based) or integrate league/oauth2-server directly. FOSOAuthServerBundle's ecosystem has moved on.
• You need security responsiveness. Zero stars and zero dependents means no community CVE triage, no downstream pressure, no one else noticing a vulnerability before you do. OAuth2 is a security-critical surface — this is disqualifying for anything customer-facing.
• You're starting something new. A single-maintainer fork with a three-year-old release and no adoption is a supply-chain liability, not a foundation.
• You need OIDC, PKCE, rotating refresh tokens, or modern grant hardening. Expect to implement or backport these yourself.

How to Pitch It (Stakeholders)

To executives: This is not a candidate for adoption. It is a low-adoption, single-maintainer fork of an abandoned Symfony OAuth library, and it does not work with our Laravel stack at all. The strategic point worth funding is the capability, not the package: OAuth2/OIDC issuance should be delivered on a maintained, community-audited library — Laravel Passport or League's OAuth2 server — because authentication is a security-critical surface where "one person's fork" is unacceptable supply-chain risk. If any team is currently depending on this fork, treat it as technical debt with a scheduled migration, not as a dependency to standardize on.

To engineering: Do not add this. It's a Symfony bundle with no Laravel integration, zero stars, zero dependents, and a 2023 release. If a legacy Symfony service is already on FOSOAuthServerBundle, we'll allow a pinned, internally vendored copy only with a written exit plan and an owner — and only after diffing the fork against upstream to confirm what it actually changes. For anything new, the sanctioned path is Passport (Laravel) or trikoder/oauth2-bundle / League (Symfony). Flag any existing usage in the dependency inventory so we can size the migration.