Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Oauth2 Server Public Client Bundle Laravel Package

spomky-labs/oauth2-server-public-client-bundle

Symfony bundle that adds public client support to the Spomky-Labs OAuth2 server, enabling clients that cannot keep secrets—such as mobile and browser-based apps—to obtain tokens securely with authorization code and PKCE flows and integrate easily into Symfony applications.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for auth infrastructure. This bundle is a data point in the "roll your own OAuth2 authorization server" decision. It shows how a framework-native, DI-configured OAuth2 server used to be packaged for Symfony — useful context when scoping whether in-house auth is a few weeks of configuration or a multi-quarter security commitment.
  • Public client support on the roadmap. The package's entire reason for existing is the "public client" grant type — mobile apps, SPAs, and CLI tools that cannot keep a client secret. If any roadmap item involves first-party mobile or browser-based clients, public-client flows (PKCE, no-secret registration) are a hard requirement, not an option. This package is a concrete artifact of that requirement.
  • Legacy/maintenance triage. Zero stars, zero dependents, and a Symfony 2 target place it firmly in the "abandoned" bucket. That informs decisions about whether to fund migration off an existing integration versus extending it, and how to score it in a tech-debt backlog.
  • Vendor and ecosystem risk assessment. A PM evaluating the Spomky-Labs OAuth2 family needs to know this is a thin config bundle layered on a broader library, not a self-contained product. Dependency-graph decisions (which layer do we actually depend on, and who maintains it?) flow from that.
  • Market/competitive signal. The existence of a dedicated bundle for one grant type, now unmaintained, is evidence that the PHP OAuth2 ecosystem consolidated around a few winners. That reinforces "adopt the maintained standard, not the niche config wrapper."
  • Not a Laravel decision. Despite the framing, this is a Symfony 2 bundle with no Laravel integration. It should not appear in any Laravel build-vs-buy comparison; Laravel Passport or an external IdP owns that slot.

When to Consider This Package

Consider it only if:

  • You are maintaining an existing Symfony 2 application that already depends on the Spomky-Labs OAuth2 server stack, and you need to understand or patch its public-client configuration.
  • You are doing archaeological research on how public-client OAuth2 flows were wired via Symfony DI, e.g., to inform a migration plan or a design doc for a replacement.
  • You need a reference implementation to compare against a proposed internal design.

Look elsewhere if:

  • You are starting anything new. Symfony 2 is end-of-life; there is no security patch path, and a security-critical component on an EOL framework is an unacceptable risk.
  • You need community support, CVE response, or documentation. Zero stars and zero dependents means effectively no users, no issue triage, and no one to ask.
  • You are on Laravel. There is no Laravel integration here; use Laravel Passport/Sanctum or delegate to a hosted IdP.
  • You need modern public-client support. Current best practice is authorization code + PKCE, which is better served by actively maintained libraries (league/oauth2-server with its Symfony bundle, oauth2-server-php successors) or a dedicated authorization server (Keycloak, Ory Hydra, Auth0, AWS Cognito).
  • You cannot afford to own the code. Adopting an unmaintained bundle means forking and maintaining it; price that in before adopting.

Adoption criteria checklist: active maintainer within 12 months, supported framework version, nonzero dependent count, documented security policy, and a clear upgrade path. This package fails all five.

How to Pitch It (Stakeholders)

To executives: This is a legacy configuration bundle for OAuth2 servers on Symfony 2, an end-of-life framework. It has no measurable adoption and no maintenance signal. We should not adopt it and should not budget around it. The strategic takeaway is narrower: if our roadmap includes mobile or single-page clients, we need public-client OAuth2 support — but we should buy or use a maintained, standards-compliant implementation rather than build on an abandoned one. Treat this package as evidence for the requirement, not as a candidate solution.

To engineering: Do not add this as a dependency. It is a thin Symfony 2 DI bundle for public-client configuration on top of the Spomky-Labs OAuth2 server; the framework target is EOL and the package is unmaintained, so any security issue becomes ours to fix. Use it only as a read-only reference for how public-client grants were configured. For new work, standardize on authorization code + PKCE via a maintained library or a dedicated IdP, and if we are on Laravel, use Passport or an external provider. If we discover an existing internal dependency on this stack, flag it for migration planning and estimate the fork-and-own cost before we defer it again.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums
rlacerda83/query-parser
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings