Product Decisions This Supports
- Build vs. buy for outbound OAuth egress: The core question this package answers is whether social/OAuth login must traverse an HTTP proxy (corporate network, egress-restricted VPC, regulated environment). That's a platform constraint, not a feature. Decide once, at the platform level, and encode it as an architecture standard rather than letting it leak into individual login integrations.
- Framework standardization for the auth surface: Despite the "Laravel/PHP" framing, this is a Symfony bundle for HWIOAuthBundle. Adopting it tacitly commits you to Symfony + HWIOAuthBundle for the auth path. That is a roadmap-level decision, not a package-level one — and it should be made explicitly.
- Scope of "proxy" support in the login roadmap: Proxy support is a small, unglamorous slice of the auth story. It rarely belongs on a roadmap as a line item, but it belongs in the definition of done for "social login works in all target deployment environments."
- Vendor-and-own vs. depend: The functionality is thin enough (wrapping HTTP client configuration for OAuth token/userinfo calls) that the realistic options are (a) ~50 lines of in-house Symfony service decoration, or (b) a dependency. This package's profile (1 star, 0 dependents) makes (a) the defensible default.
- Migration/legacy pressure: HWIOAuthBundle itself is effectively in maintenance limbo and tied to older Symfony majors. Any decision here is also a decision about how long you intend to keep a legacy auth stack alive.
When to Consider This Package
Consider it only in a narrow, self-hosted Symfony scenario:
- You already run HWIOAuthBundle in production and are not migrating off it this cycle.
- You have a hard, non-negotiable requirement that OAuth provider calls (token exchange, userinfo) go through a forward proxy — typically an egress-filtered network, an on-prem deployment, or a compliance mandate.
- You are prepared to fork and own it: audit the code, pin the commit or fork into a private VCS, and accept responsibility for security patches. With 1 star and 0 dependents, you are the maintainer the moment you install it.
- The alternative — hand-rolling proxy configuration on your HTTP client — is genuinely more expensive than reading and adopting this code.
Look elsewhere when:
- You are on Laravel — this is not for you; Socialite plus Guzzle's
proxy option covers the same ground natively.
- You are not already on HWIOAuthBundle — do not adopt HWIOAuthBundle in order to adopt this. The dependency chain is upside-down.
- You need active maintenance, security response, or a support contract — none exists here. Zero dependents means zero community pressure to fix anything.
- You need proxy support for OIDC, SAML, or non-HWI providers — this scopes to HWI's resource-owner flow only.
- Your proxy requirement can be met at the infrastructure layer (NAT gateway, egress proxy with DNS interception, sidecar). Solving networking in the network is almost always cheaper than solving it in application code, and it keeps auth code provider-agnostic.
How to Pitch It (Stakeholders)
For executives: This is a tiny, single-purpose add-on that lets an existing Symfony login stack route OAuth traffic through a proxy. It is not a strategic dependency and we are not recommending adoption. It has one star, no downstream users, and no maintainer activity — meaning we would inherit full ownership and security liability on day one. The capability it provides is small enough to build ourselves in roughly a day and keep under our own control.
For engineering: Treat this as reference code, not a dependency. Read it to learn the HWI extension seam, then implement proxy configuration directly on your HTTP client (or, better, resolve egress at the network layer so no application code changes at all). If you do install it, fork it, pin it, and add it to your vulnerability-watch list — there will be no upstream fixes. Separately: flag that HWIOAuthBundle is on the legacy path, and use this as a data point in the broader "when do we migrate the auth stack" conversation.
The honest one-liner: Correct solution to a real but narrow problem, shipped by one person, adopted by nobody. Useful to read; risky to depend on.