Oauth2 Server Password Client Bundle Laravel Package

Product Decisions This Supports

• Scoping auth work on a legacy Symfony 2 codebase. This bundle is a configuration shim for wiring a "password client" (Resource Owner Password Credentials grant) into an OAuth2 server built on the Spomky-Labs/Symfony2 stack. It is only relevant as part of an inventory of what already exists in an old auth stack — not as a forward-looking dependency for new work.
• Build vs. buy for authentication. It represents the "buy" end of the spectrum for a narrow slice of OAuth2 configuration (password grant client setup), in the specific ecosystem of Symfony2 + Spomky OAuth2 server. It does not cover token issuance logic, storage, or security hardening — those live in the underlying libraries and in your own integration.
• Roadmap input: password grant deprecation. The package's core purpose — configuring a password-grant client — is the exact flow OAuth 2.1 and modern security guidance de-emphasize in favor of Authorization Code + PKCE. This is a signal to schedule a roadmap item to replace password-grant usage in any product still relying on it.
• Use cases the package historically enabled. First-party mobile apps or internal admin tools that needed quick token acquisition against a Symfony2-hosted OAuth2 server. These use cases are better served today by managed identity providers or modern libraries.
• Technical-debt accounting. With zero stars, zero dependents, and Symfony2-era lineage, this package belongs in a "sunset / do not extend" bucket in the dependency audit rather than in any active feature planning.

When to Consider This Package

• Only if you are responsible for a running Symfony 2.x application that already depends on the Spomky-Labs OAuth2 server family and you need to add or adjust configuration for a password-grant client — and only as a maintenance change, not for new capability.
• When your security review has explicitly accepted the Resource Owner Password Credentials grant for a first-party, high-trust client (e.g., an internal tool) and the alternative is more migration cost than the project can absorb this cycle.
• When the work is time-boxed to "keep the lights on" and you have a concrete migration path off Symfony 2 already funded.

Look elsewhere if:

• You are starting a new project, or you are on Symfony 3.4 or later. The *Bundle naming convention and Symfony2-era wiring assumptions make this a poor fit for modern Symfony (Flex recipes, autowiring, the Bundle suffix no longer being idiomatic).
• You need OAuth 2.1 alignment, PKCE, SPA or native-app flows, or modern token lifetimes — use League OAuth2 Server, Symfony's native authenticators, FOSOAuthServerBundle (for maintained Symfony versions), or a managed provider (Auth0, Keycloak, Ory Hydra, Cognito).
• You need anything resembling vendor support, a security response process, or an active maintainer. Zero stars and zero dependents is not itself disqualifying, but combined with Symfony2 lineage it strongly suggests the project is effectively abandoned.
• You are choosing an authentication approach for a customer-facing product where security posture and long-term maintenance are product requirements, not incidental concerns.

How to Pitch It (Stakeholders)

For executives: This package is a narrow, Symfony2-era configuration helper for a specific OAuth2 flow (password grant) that modern security guidance is moving away from. It has no meaningful community adoption and no evident maintenance. Recommendation: do not adopt it for anything new. If it is already in our stack, treat it as technical debt to be retired — the question is not "should we use it?" but "how fast can we migrate off it?" The strategic move is toward a managed identity provider or a maintained library, which reduces both security risk and long-term engineering cost.

For engineering: This is a config shim for the Spomky-Labs OAuth2 server on Symfony 2 that wires up a password-grant client. It is unmaintained, unadopted, and tied to a framework version we should not be building on. Do not introduce it into new services. If we inherit it, isolate it behind our own auth interface so the underlying implementation can be swapped without touching product code. Any migration should target Authorization Code + PKCE (or a hosted IdP) and a currently supported Symfony version. Estimate the migration as a discrete roadmap item, not a background chore — the dependency will not get safer over time.