Rabbitmq Access Token Bundle Laravel Package

Product Decisions This Supports

• Choosing a broker credential strategy, not a library. The real decision on the table is "long-lived RabbitMQ username/password in env vars" versus "short-lived OAuth 2.0 access tokens with automated refresh." That is a security and compliance posture question with a roadmap owner. The package is only one possible implementation of the refresh half.
• A build-vs-buy call that resolves to "build the seam, borrow the design." Measured honestly: the scope this package covers is small — a token provider service, an expiry-aware refresh path, and configurable endpoint/credentials. As a Laravel dependency it isn't buyable at all (it is a Symfony bundle), and with zero stars, zero dependents, and a last release of 2020-05-03, it fails the maintenance gate outright. The defensible PM decision is a time-boxed spike that reads this bundle's shape as a reference and lands a TokenProvider contract plus one implementation behind it in our own code (roughly 1–3 engineer-days including tests).
• Roadmap acceleration — conditionally. It only accelerates work that is already committed: rolling out the rabbitmq_auth_backend_oauth2 plugin, retiring static broker credentials, per-service identity for publishers/consumers, or secret-rotation compliance. If token auth isn't on the committed roadmap, this package supports no decision and should not consume a spike.
• Platform standardization. If more than one PHP service (Laravel or Symfony) talks to RabbitMQ, this is a "converge on one refresh approach" decision. Our abstraction should be the standard, with any third-party code sitting behind it.
• Representative use cases to map against the roadmap: replacing static broker credentials ahead of an audit; scoping queue access per tenant/service via token claims; removing a hand-rolled refresh job with known edge cases around clock skew and expiry races.
• Risk ownership. This is authentication surface. A five-year-stale, single-maintainer, zero-adoption package on the path to production is a supply-chain and continuity risk that needs a named owner — which is itself a reason the decision lands on in-house code.

When to Consider This Package

Adoption criteria — and this package's standing against each:

• Framework fit. Fails for a Laravel codebase: it is a Symfony bundle with no service provider, config publishing, or facade. Reusable only behind a hand-written adapter, and only worth it if you already run Symfony 4/5 services alongside Laravel.
• Maintenance signals. Fails. Last release 2020-05-03, no dependents, no stars, no evident triage or support window. Acceptable as a read-only reference, not as a pinned dependency.
• License and governance. Verify the license before reading code into our repo; treat maintainer continuity as absent and plan accordingly.
• Convention overlap. Low for Laravel. The integration cost is entirely ours, which erodes the "buy" argument to nearly zero.
• Exit cost. Low, because the surface is small and narrow. That is precisely the argument for writing it ourselves behind a contract rather than importing it.
• Dependency footprint. Proportionate — described as lightweight and framework-agnostic, with no heavy transitive tree. This is its one genuinely favourable signal.

Look elsewhere or build in-house when: you are on Laravel (use the HTTP client or Saloon to call your token endpoint, plus a small TokenProvider contract); you need a supported, upgrade-safe dependency on a revenue path; or you need behaviour you can explain to auditors and support without reading unmaintained vendor code. Consider this bundle only as a design reference during a spike, or as a stopgap on an existing Symfony service with a hard deadline and an accepted risk note.

How to Pitch It (Stakeholders)

To executives: The strategic question is whether we retire static RabbitMQ passwords in favour of short-lived, automatically refreshed access tokens. That is an audit and incident-blast-radius win, and it is coming either way. The specific library proposed for it has no adoption, no releases since 2020, and targets a different framework, so we are not asking to depend on it. We are asking for a small, time-boxed spike — a defined interface plus one implementation behind it — costed in days, not weeks. Because the surface is narrow and sits behind our own contract, the decision is reversible: if we later find a maintained package, we swap the implementation and keep the interface.

To engineering: Treat this as a pattern to read, not a package to install. Define the seam first — a TokenProvider contract exposing getToken() and refresh() with expiry-awareness — and make AMQP connection config consume it. Keep our tests running against the contract, never against vendor internals. Model the refresh path explicitly (refresh-before-expiry, clock skew, concurrent consumer fan-out, failure backoff); that is where the bugs live, not in the plumbing. Pin the broker plugin version and confirm its token semantics before we build. If we ever import code, it goes behind the adapter with a fork/exit note in the ADR.

Decision requested: approval for a 1–3 day spike to land the token-provider contract and one implementation behind it, using this bundle as reference only — with a go/no-go review gated on confirming the broker's OAuth 2.0 support, our token endpoint's refresh semantics, and the operational runbook for rotation. No production dependency on letdoittoday/rabbitmq-access-token-bundle is proposed.