Oauth2 Server Scope Manager Bundle Laravel Package

Product Decisions This Supports

• OAuth2 scope governance for legacy Symfony2 services — If your platform still runs a Symfony2-era authorization server, this bundle is the plug-in that gives you persistent, manageable scopes (create/read/update/delete) rather than hard-coded strings. That directly supports access-control roadmaps: defining API permissions, mapping scopes to client grants, and enforcing least-privilege at the token layer.
• Build vs. buy for consent and scope UI — The package supplies the storage/manager layer behind a scope admin screen. A PM can use it to decide whether to build an internal "scope registry" admin or buy a managed identity provider; this bundle is a build-side accelerator only for Symfony2 stacks.
• Feature scoping for API productization — When defining public API tiers (read-only, write, admin), the scope model here informs how granular your product's permission matrix should be, and how much of that is delegated to the auth server versus the application.
• Roadmap prioritization for auth modernization — Because this is a Symfony2-only, end-of-life artifact, it is most useful as a decision input: it quantifies the cost of maintaining a bespoke scope manager versus migrating to a maintained OAuth2 library or a managed IdP.
• Use cases it actually fits — Maintaining an existing Symfony2 application that already depends on Spomky-Labs/OAuth2ServerBundle; internal R&D or reference implementations; not greenfield work, and not Laravel.

Important caveat for a Laravel/PHP PM: this is a Symfony2 bundle, not a Laravel package. It has no Composer ecosystem overlap with Laravel, no stars, no dependents, and targets a framework that has been end-of-life since 2018. Treat it as a reference design, not a dependency.

When to Consider This Package

Consider it only when all of the following are true:

• You are maintaining a Symfony2 application that already uses the companion Spomky-Labs/OAuth2ServerBundle and its scope-manager interfaces.
• You need Doctrine-backed CRUD for OAuth2 scopes and would otherwise hand-roll the same persistence layer.
• The cost of adopting a thin, unmaintained bundle is lower than rewriting the authorization path — i.e., the service is in maintenance, not growth.
• Your security review accepts an unsupported dependency, with a documented plan and owner for eventual replacement.

Look elsewhere when:

• You are on Laravel. Use Laravel Passport (full OAuth2 server with first-class scope support) or Laravel Sanctum for token abilities. Neither needs this bundle, and mixing Symfony bundles into Laravel is not a supported integration.
• You are on Symfony 4/5/6/7. Use league/oauth2-server with the maintained Symfony bundle, or a managed provider (Auth0, Keycloak, Okta, Cognito).
• You need an actively maintained dependency. Zero stars, zero dependents, and a Symfony2 target mean no security patching, no community support, and high bus-factor risk. For anything customer-facing, this fails a standard build-vs-buy review.
• You want managed scope/consent UX. A managed IdP delivers scope registries, consent screens, and audit trails as product features; hand-rolling on an abandoned bundle is a false economy.

How to Pitch It (Stakeholders)

To executives: This package is a small, unmaintained plugin for a retired version of a PHP framework. It solves a real problem — storing and managing OAuth2 permission scopes in an admin-editable way — but it is not a strategic asset. There are no stars, no downstream users, and no maintainer activity. I recommend we do not adopt it for any new product. Its value to us is as a reference architecture for how a scope registry should be modeled, and as a migration-cost data point if we still own Symfony2 services. Any customer-facing auth work should go to a maintained library (Laravel Passport) or a managed identity provider, both of which reduce long-term security and compliance risk.

To engineering: This is a Symfony2 bundle from the Spomky-Labs OAuth2 server family; it provides the Doctrine-backed scope manager (CRUD for scopes) behind the authorization server. It is not a Laravel package and cannot be dropped into a Laravel app. If we have a live Symfony2 service on OAuth2ServerBundle, reusing it is cheaper than writing persistence ourselves — but budget an exit path, because the framework is EOL and the bundle has no maintainers. For everything else, the comparable choices are league/oauth2-server (framework-agnostic, maintained) or Laravel Passport (if Laravel). Please treat the bundle's data model as the requirement spec, not the implementation.