Rabbitmq Access Token Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle (bundle class + DI extension), not Laravel-native. There is no service provider, no publishable config, no Laravel facade/contract. The README's "framework-agnostic" claim describes the token-fetching logic, not the integration surface.
• What is actually reusable in a Laravel app is the pattern: a service that performs an OAuth client_credentials-style token request against the RabbitMQ OAuth2 token endpoint, caches the token, and refreshes it before expiry. That is on the order of 100–300 lines of code.
• Scope is narrow and correctly bounded: it is client-side credential acquisition only. It does nothing for the broker side — rabbitmq_auth_backend_oauth2 plugin enablement, signing keys, resource_server_id, scope-to-vhost/permission mapping, or token TTL policy. Adopting it does not reduce the platform work; it reduces only the smallest piece of it.

Integration feasibility

• As a dependency: low value, non-trivial friction. Installing it into a Laravel app drags Symfony DI components in for one convenience class, requires manual bundle registration (Flex discovery won't apply), and leaves you with a service you still have to adapt to Laravel's container and queue config.
• As a reference implementation: high feasibility. The behavior we need can be reimplemented natively in a TokenProvider bound to a Laravel contract, backed by Cache and an atomic lock, with credentials sourced through the existing secret manager.

Technical risk

• Abandoned. Last release 2020-05-03, zero stars, zero dependents, single-org maintainer. It predates PHP 8, Laravel 8+, and modern Symfony. There is no compatibility statement, no changelog discipline, no CVE response path.
• No field validation. Zero dependents means no evidence that the token-refresh logic works against a real broker under load, clock skew, or IdP latency. We would be the first production validator.
• Refresh semantics are the real risk. Refreshing a token in the app does not re-authenticate an already-open AMQP connection unless the client supports credential update on a live connection. Long-lived queue workers will outlive the token and fail on reconnect — a failure mode this package cannot solve and does not document.
• Governance unknowns. License must be verified before any code is vendored; "no heavy dependencies" is a claim, not a lockfile.
• Secret handling. Token endpoint client secrets become another credential to place in config; a 2020-era bundle's config conventions likely predate modern secret-manager practice.

Key questions

1. Which RabbitMQ version, and is rabbitmq_auth_backend_oauth2 enabled and validated in staging? Who owns that?
2. Does our AMQP client (e.g. php-amqplib via vladimir-yuldashev/laravel-queue-rabbitmq) support updating credentials on a live connection, or must we cap connection lifetime below token TTL?
3. Who owns the token endpoint, its TTL, and its availability SLO — and what happens to queue throughput if it is down?
4. What is the package's license, and are we permitted to vendor and modify the provider logic?
5. What is our target Laravel/PHP version, and can we test against a dockerized broker this sprint?

Integration Approach

Stack fit

• Laravel resolves RabbitMQ connection credentials at worker boot. That means token acquisition happens at process start and on reconnect — so the practical design is: fetch a cached token at boot, keep connection lifetime bounded below token TTL, and never rely on mid-connection refresh.
• Recommendation: do not adopt the package as a dependency. Port the pattern behind a contract. It is a small, well-understood piece of code, and owning it eliminates the Symfony/Laravel impedance mismatch entirely.

Migration path

1. Spike (time-boxed, ~1 engineer-week): stand up RabbitMQ with the OAuth2 plugin in docker, confirm scope/vhost mapping, and prove a Laravel worker connects with a token instead of user/password.
2. Contract: define App\Contracts\AmqpTokenProvider (token(): string, invalidate(): void). All app code and tests depend on the contract, never on any vendor class.
3. Implementation: CachedAmqpTokenProvider — Redis cache keyed by audience, atomic lock around refresh, jittered early refresh (e.g. at 70% of TTL), structured logging and metrics on fetch latency and failure.
4. Wiring: a small service provider that decorates the queue connector's config with ['password' => $token, 'username' => ''] or the plugin's expected credential shape.
5. Cutover: feature flag per environment; keep static password credentials configured and disable-able so rollback is one config change, not a redeploy of code.

Compatibility

• If any code is vendored, rewrite it for PHP 8.2+/Laravel 10+ rather than patching a 2020 codebase. Verify the license first.
• Compatibility risk is concentrated in the broker and client, not the bundle: confirm the AMQP client version handles token-based login and behaves on token rejection.

Sequencing

• Broker/platform work first (plugin, keys, scopes, TTL policy) → token endpoint SLO and rate limits second → client integration third. Starting client work before the broker is validated in staging is the classic way to burn a sprint on a 403 that is really a scope-mapping misconfiguration.

Operational Impact

Maintenance

• Either path is self-maintained in practice; the difference is whether we carry a dead dependency or a two-file internal class. The internal class wins on auditability, upgrade cost, and CVE surface. Budget the port once, not an annual upgrade tax.

Support

• With 0 stars and a 2020 release, there is no upstream support channel. Escalation is us, regardless. That removes most of the "buy vs. build" argument for taking the dependency.

Scaling

• The token endpoint becomes a boot-path dependency for every worker. N workers × M restarts per deploy will hammer the IdP unless tokens are cached centrally and refreshed by a single lock holder per TTL window. Expect to need IdP rate-limit headroom and a cold-start latency budget on deploy.
• Long-lived consumer pools must have their max connection age set below token TTL, or be restarted on a cadence — a supervisor/ops policy, not a code concern, and one that must be written down.

Failure modes

• IdP unavailable → workers cannot boot → queue backlog grows silently. Needs a health check and an alert on token-fetch failure rate, not just on queue depth.
• Clock skew → premature 401s; require NTP discipline on workers.
• Token expiry mid-connection → consumer stalls or enters a reconnect loop; mitigate with bounded connection lifetime.
• Refresh stampede → IdP throttling; mitigate with locking and jitter.
• Broker-side scope/audience misconfiguration after a change → mass 403s across all consumers; stage-gate broker changes.
• Token leakage into logs or exception traces — tokens must be redacted at the logging boundary from day one.

Ramp-up

• Low for any engineer who has done OAuth client credentials; the concept is familiar. The absence of documentation beyond a README, and the RabbitMQ plugin specifics (scopes, resource_server_id, permission mapping), are where the real learning cost sits — plan a short internal runbook covering token refresh, connection lifetime policy, and rollback to password auth.

Bottom line for the decision review: approve the time-boxed spike, but scope it to porting the pattern, not adopting the bundle. Gate the go/no-go on broker-side plugin validation, verified license for any vendored code, and a working rollback flag.