- How do I install bmatovu/oauth-negotiator in a Laravel application?
- Install it with Composer using composer require bmatovu/oauth-negotiator, then publish the package's config file with the vendor:publish command and inject the token manager where you make outbound API calls. Integration is mechanically simple: a service provider, a config file, and a manager object that acquires and caches client_credentials tokens. Before installing, confirm the vendor and repository names on Packagist, since the package vendor is bmatovu while the GitHub repository owner is mtvbrianking.
- Which Laravel and PHP versions does oauth-negotiator support?
- The last release was published on 2022-03-26, which predates Laravel 10, 11, and 12 as well as PHP 8.2 and 8.3, so the declared illuminate/* and PHP constraints need verification on Packagist before you commit. On a modern Laravel estate you should expect to apply a compatibility patch or maintain a fork that bumps those constraints. Check the transitive dependencies too, particularly the Guzzle major version and cache contracts.
- Does this package support authorization code or PKCE flows, or only client_credentials?
- Its stated scope is a client_credentials token manager for service-to-service calls, with no indication of authorization-code, PKCE, refresh-token, OIDC identity assertions, token exchange, or DPoP-bound tokens. If your requirements include per-end-user delegated consent or zero-trust token binding, this package is a poor fit. Treat it as a narrow machine-to-machine helper rather than a general OAuth2 client.
- How does oauth-negotiator cache OAuth2 access tokens, and can I use Redis?
- The manager acquires and caches client_credentials tokens, but the cache key scheme and driver assumptions are not documented in the overview, so verify them in the source. Confirm whether it assumes the file cache driver and whether it tolerates a Redis-backed store with multiple tenants, environments, and queue workers sharing the same instance. Also check whether raw token values are written to cache in plaintext and how keys are namespaced to avoid collisions.
- Where should I store OAuth client secrets when using this package?
- Credentials are expected to come from the publishable config file, so read them from environment variables or a secrets manager rather than committing them to version control. Confirm from the source that secrets and tokens cannot leak into logs, exception messages, or serialized cache values. Because this sits in the token path, a short review of the credential handling is worthwhile before production use.
- Is bmatovu/oauth-negotiator safe to use in production given its last release was in 2022?
- The technical risk is high and dominated by lifecycle rather than any known defect: the package is dormant, has roughly 3 stars, 0 dependents, a single maintainer, and no visible CI, static analysis, or security policy signal. Zero dependents is the most telling number, because it means almost no field hardening or downstream compatibility fixes. If you adopt it, pin to a commit hash rather than a floating constraint, vendor or fork it, and get explicit security sign-off for a dormant dependency in the token path.
- How does oauth-negotiator handle token expiry and refresh when multiple queue workers run?
- The package caches tokens, but whether it implements locking, jitter, or pre-expiry prefetch to prevent an identity provider stampede is not stated, so test it with several queue workers sharing a cache. Client_credentials flows typically re-request a token on expiry rather than using a refresh token, which makes concurrent expiry a realistic concern. If the package does not coordinate this, wrap the manager with a cache lock or a pre-expiry refresh routine.
- Can I use oauth-negotiator outside Laravel or with plain Guzzle?
- It is a Laravel-flavored package built around a service provider, a publishable config file, and a manager object, so using it in plain PHP is awkward unless the manager can be constructed independently. Check how tightly it couples to illuminate contracts and the framework's config and cache bindings. If you need framework-agnostic behavior, league/oauth2-client may be a better base.
- What alternatives should I consider for OAuth2 client credentials in Laravel?
- Laravel Socialite targets user authentication rather than machine-to-machine client_credentials, so it is not a direct substitute. Common alternatives are league/oauth2-client wrapped in your own cached token provider, a maintained token manager package, or an internal token-provider contract that lets you swap implementations. The overview also suggests defining a contract and treating this package as one implementation behind it, which reduces lock-in if you later fork or replace it.
- How do I test OAuth-protected API calls without hitting the identity provider?
- Fake the token manager or the underlying HTTP client in your test suite and seed the cache with a valid token so tests never reach the identity provider. Add explicit cases for a cache miss, an expired token, and tenant or environment key collisions, since those are the paths most likely to misbehave. If you wrap the manager behind your own interface, tests can bind a simple stub and stay independent of the package's internals.