- Is guilhermednt/hwi-oauth-proxy-bundle a Laravel package?
- No. It is a Symfony bundle that depends on symfony/framework-bundle and symfony/http-kernel and registers itself through the Symfony DI container and a Bundle class, neither of which exists in Laravel. The only things it shares with a Laravel package are Composer and PHP itself, so any bin/console or services.yaml reference in the docs should be treated as a red flag for Laravel use.
- Can I use a Symfony bundle like this inside a Laravel app?
- Only by booting a Symfony DI container inside Laravel to host the bundle, which is heavy and fragile, or by extracting the underlying proxy logic and reimplementing it as a Guzzle middleware or PSR-18 decorator. In practice the second option is 50 to 200 lines of code, which is less work than wiring Symfony's container into Laravel's request lifecycle. Read the bundle's DependencyInjection directory first; if it is only an HTTP client decorator, there is nothing worth importing.
- What does hwi-oauth-proxy-bundle actually do?
- It is described as a bundle that enables a proxy for HWIOAuthBundle, letting an app delegate OAuth requests to a remote server instead of holding provider secrets and tokens locally. The description is ambiguous: it may mean routing outbound OAuth HTTP calls through a transport proxy, or acting as an OAuth flow broker where a central app owns the client secrets. Those two interpretations have very different security and operational consequences, so confirm which one you need before evaluating further.
- Which PHP and Symfony versions does this bundle require?
- Symfony bundles of this vintage typically constrain PHP 7.x and Symfony 4 or 5, while Laravel 10 and 11 require PHP 8.1 or newer. Run composer require guilhermednt/hwi-oauth-proxy-bundle in a throwaway branch and read the composer why-not output, because a constraint conflict is the cheapest possible no. Expect the bundle's symfony/* pins to collide with Laravel's own symfony/console, symfony/http-foundation and symfony/finder transitives.
- How do I proxy outbound OAuth HTTP requests in Laravel instead?
- Configure the proxy at the HTTP client level: Guzzle accepts a proxy request option, and you can also set HTTPS_PROXY and NO_PROXY environment variables at the container level so every outbound call is covered. Laravel Socialite and league/oauth2-client both ride on Guzzle, so the setting applies to token and userinfo requests without any extra package. This adds zero dependencies and keeps the proxy concern separate from your authentication code.
- How do I build a centralized OAuth broker in Laravel?
- Use Socialite's custom provider support via Socialite::buildProvider with your own provider class, and keep the client secrets in one first-party service that other apps redirect through. Socialite is documented and maintained, and a custom provider is a small, testable class rather than a second framework's bundle. A dedicated auth service with its own token endpoints is usually clearer than an in-process proxy.
- Is HWIOAuthBundle still maintained?
- It is largely dormant, and the Symfony ecosystem has moved toward knpuniversity/oauth2-client-bundle and Symfony's native OAuth2 client support. Adopting hwi-oauth-proxy-bundle means inheriting two layers of unmaintained dependency for one narrow capability. Check the last commit date and open issue counts on both repositories before committing to anything.
- Is this package safe to use in production for OAuth?
- Its security posture is unverified: it has around one star, zero dependents, no CVE history and no third-party audit, which means you would be the first meaningful consumer. OAuth code touches client secrets and bearer tokens, so ask specifically whether the proxy logs request bodies and how it handles token refresh. With no crowd-sourced bug discovery, you would also be the one finding the edge cases.
- Does this bundle work with Laravel Socialite?
- No. Socialite and HWIOAuthBundle are separate abstractions with different provider interfaces, and Socialite does not consume Symfony bundles. If you want Socialite traffic behind a proxy, configure Guzzle's proxy option or the HTTPS_PROXY environment variable rather than introducing a second auth stack. Mixing the two would leave you maintaining two OAuth implementations in one application.
- Is there a test suite, and how do I test the proxy failure paths?
- The repository footprint is minimal and there is no documented test suite, so check for a tests directory and CI configuration before relying on it. If you do extract the proxy logic, cover the failure modes yourself: unreachable proxy, upstream 5xx responses, malformed or expired tokens, and timeout behavior. Those are exactly the paths a thin, untested client decorator tends to miss.