Read RabbitMQ OAuth scopes as broker permissions, not login metadata

OAuth 2.0 can replace local RabbitMQ users with tokens issued by an identity provider. Authentication is only half of the change. The broker still needs a deterministic mapping from token claims to virtual hosts, queues, exchanges, and management actions. In RabbitMQ, that mapping is expressed through scopes and tags. A successful token validation does not imply that the resulting permissions are narrow.

The token carries policy inputs

RabbitMQ's OAuth 2.0 backend validates JWT access tokens and translates scopes into permissions. The access token must include scopes the broker supports. Operators can choose a different claim field through auth_oauth2.additional_scopes_key when the identity provider places roles or scopes somewhere other than the default field.

When one RabbitMQ cluster trusts more than one OAuth resource server, those servers are configured under auth_oauth2.resource_servers.<index> .…