- Is kamermans/guzzle-oauth2-subscriber a Laravel package or just Guzzle middleware?
- It is a framework-agnostic Guzzle middleware/subscriber, not a Laravel package. There is no Laravel service provider, config file, or native integration with Laravel's HTTP client. In Laravel you wire it manually into a dedicated Guzzle client and bind that client in the container. It is best used for outbound API calls, not for implementing an OAuth2 server or social login.
- How do I install and configure guzzle-oauth2-subscriber in a Laravel app?
- Install it with Composer alongside Guzzle 7, then construct a Guzzle client and attach the OAuth2 subscriber or middleware. Plan to create the token configuration, grant type, and token persistence yourself, because the package does not ship Laravel configuration. Bind the configured client as a singleton and inject it into the services that call the external API. Keep the setup scoped to the providers that actually need OAuth2 bearer tokens.
- Which OAuth2 grant types does this package support?
- It supports Authorization Code, Client Credentials, Resource Owner Password, and Refresh Token grants, plus custom grants. For machine-to-machine Laravel integrations, Client Credentials and Refresh Token are usually the relevant flows. Authorization Code can be used, but your application must own redirects, callbacks, and per-user token storage. Verify that the grant you need is covered before adopting it.
- Does guzzle-oauth2-subscriber work with Laravel's Http facade?
- Not natively; the package is built for Guzzle clients. Integration through Laravel's Http facade may be possible only if you can cleanly attach the middleware or handler for your Laravel version. The safer approach is a dedicated Guzzle client with the OAuth2 subscriber for OAuth2-protected APIs. Do not assume the facade will handle token refresh or persistence for you.
- How does automatic token refresh work and how do I avoid refresh stampedes?
- The subscriber attaches access tokens and refreshes them when credentials expire. In multi-instance production, you must design persistence and locking so concurrent requests do not all refresh the same token at once. Use a shared store such as Redis or the database with a distributed lock around refresh. Also review how the package handles 401 responses to avoid retry loops.
- What token persistence options are available and can I use Laravel cache or database?
- The package provides pluggable token persistence, including in-memory and file-based storage, and supports custom implementations. File-based persistence is not suitable for multi-instance Laravel production. Implement the token persistence contract against Laravel Cache, Redis, or the database with encryption and locking. Key tokens by provider, subject, and scopes where appropriate.
- Is PHP 8.4 and Laravel 11 or 12 supported by v1.1.1?
- Version 1.1.1 is a targeted patch for nullable deprecations on PHP 8.4 and later. It reduces forward-compatibility warnings but does not declare or test a full support matrix for Laravel 10, 11, or 12. Historical Composer constraints may still need review, and the fix addresses deprecation notices rather than guaranteeing runtime correctness. Treat PHP 8.4 as deprecation-clean, not officially supported, until composer.json and CI are updated.
- How should I handle expired, revoked, or malformed tokens with this subscriber?
- The subscriber supports automatic refresh and configurable exception handling for failed authentication. You should still define application behavior for revoked or malformed tokens that cannot be refreshed. Avoid unbounded 401 retries and make failures observable through logs and metrics. Test these paths explicitly before relying on the package in production.
- Can I scope OAuth2 authentication to specific hosts or external APIs?
- The package is middleware for a Guzzle client, so the cleanest scoping is to use a dedicated client per external provider or tenant boundary. Do not apply OAuth2 middleware globally to all outbound traffic unless every target expects the same bearer token. Separate clients also make token storage keys, scopes, and refresh policies easier to manage. This keeps credentials from leaking to unrelated services.
- What are alternatives to guzzle-oauth2-subscriber for OAuth2 in Laravel?
- Laravel Passport is for OAuth2 server responsibilities, while Socialite is for social login, so neither replaces this outbound Guzzle middleware use case. Alternatives include building token injection and refresh in a dedicated Guzzle client or using a provider-specific SDK. A dedicated identity provider can also own token issuance and lifecycle. Choose based on whether you need outbound client auth, user login, or an OAuth2 server.