Rabbitmq Access Token Bundle Laravel Package

Getting Started

The first thing to internalize: this is a Symfony bundle, not a Laravel package. There is no extra.laravel.providers auto-discovery, no php artisan vendor:publish, no facade, and no config file published into config/. Composer will install it, but Laravel will not wire it up for you. Read composer.json first and confirm its symfony/* and php constraints actually overlap with your runtime — a 2020-era bundle was almost certainly built against Symfony 4.4/5.0 and PHP 7.2–7.4.

Before touching code, confirm the broker side, because this is where most of the value (and most of the failure) lives:

1. RabbitMQ must have rabbitmq_auth_backend_oauth2 (or equivalent) enabled and configured with a signing key and resource-server settings. A stock RabbitMQ will reject the token.
2. You need an OAuth2/IdP token endpoint (Keycloak, Auth0, etc.) and a client-credentials grant that yields a bearer token with the scopes the broker's resource server expects.
3. Decide whether you consume the bundle's token provider (the retrieval + refresh logic) or only copy its idea. Given the maintenance signals, treat the provider as a reference implementation you may re-implement in ~80 lines of Laravel-native code rather than a hard dependency.

A minimal first use case is the smallest possible: obtain a token from the token provider, then establish a single php-amqplib connection using that token as the password (RabbitMQ OAuth2 carries the bearer token in the password field; the username is effectively ignored). Publish one message and confirm it lands in the queue. If that works, the rest of the work is lifecycle management.

Where to look first in the repo: the token provider service class and its constructor signature. That is the only piece with real logic; everything else is Symfony container plumbing you will not use.

Implementation Patterns

There are three realistic integration shapes, from lowest to highest effort.

Pattern A — Use the token provider as a plain object. Instantiate the provider manually in a small Laravel service, feed it the endpoint/client credentials from config/services.php, and expose a token(): string method. This skips the bundle's container wiring entirely and avoids dragging Symfony's DI into your app. Wrap it behind your own interface (e.g. App\Contracts\RabbitTokenProvider) so tests and future swaps do not touch vendor code.

Pattern B — Bridge into the Laravel AMQP queue driver. The common Laravel AMQP queue driver is vladimir-yuldashev/laravel-queue-rabbitmq. It builds a php-amqplib connection from config/queue.php. Since the token changes over time, do not bake it into config at boot; instead register a container singleton that returns the current cached token, and override the connection factory (or decorate the connector) so it reads the password from that singleton at connect time. Cache the token in Laravel's cache/Cache::remember keyed off its exp claim with a safety margin, so multiple worker processes do not hammer the IdP.

Pattern C — Refresh-on-schedule. For long-running queue workers, the connection outlives the token. Two approaches work: (i) short-lived connections — reconnect per batch and re-read the token; or (ii) listen on JobProcessing/JobProcessed and compare the token's expiry against a skew window, forcing a reconnect when close. Never hold a token in memory indefinitely; the broker will validate it per-command and reject expired ones mid-stream.

For publish-only paths, Pattern A + a Cache::remember-backed token is usually enough. For consumers, plan for reconnect logic up front — an AMQPConnectionException mid-consume with an expired token is the failure mode you will hit in production.

Configure via env: token endpoint URL, client id, client secret, scope, and a refresh skew (e.g. 60–120 seconds). Keep all of it in config/services.php under a dedicated key, not scattered through the bundle's assumptions.

Gotchas and Tips

• It is a Symfony bundle. Laravel will not auto-discover it, will not publish its config, and its services are registered against Symfony's ContainerBuilder, not Laravel's container. Budget for manual wiring or extraction.
• Zero maintenance signal. Last release 2020-05-03, 0 stars, 0 dependents, single maintainer. There is no deprecation policy and no support window. Treat it as a sketch to copy, not a dependency to pin — especially on a revenue path.
• Broker prerequisites are on you. Token auth fails silently-ish if the OAuth2 plugin is not configured: you get generic auth errors that look like bad credentials. Verify the plugin, the signing key, and the token's audience/scope before debugging client code.
• Token-as-password. JWT strings are long and contain . and -/_; php-amqplib treats the password opaquely, but do not URL-encode or truncate it. Do not log it — add a redaction in your AMQP connector logs.
• Refresh races and long-lived connections. The bundle's "automatic refresh" applies to token acquisition, not to an already-open socket. You must reconnect. Centralize reconnect in one decorator so publish and consume paths behave the same.
• Clock skew. Expiry checks on the client and validations on the broker can disagree by tens of seconds. Always refresh early (skew window) and never rely on the broker accepting a token that is about to expire.
• Grant-type assumptions. Many token providers only implement the client-credentials grant. If your IdP requires a different flow (e.g. password grant for testing), you will need to substitute your own provider.
• Testing. Point the provider at a fake HTTP client (Laravel's Http::fake() or a PSR-18 mock), freeze time to exercise the refresh window, and assert reconnect happens exactly once when a token is near expiry.
• Extension point. The cleanest seam is your own RabbitTokenProvider interface; keep the vendor class behind an adapter so a future Laravel-native implementation (e.g. Cache + Http) is a one-file swap and not a rewrite.