RabbitMQ LDAP and OAuth Authentication Setup (2026)

RabbitMQ doesn’t actually do LDAP or OAuth authentication itself; it relies on plugins to bridge that gap.

Let’s say you’re setting up RabbitMQ with LDAP for user authentication and authorization, and then layering OAuth2 on top for API access. This is a common setup where your users log in via LDAP, and then your applications use OAuth2 tokens to interact with RabbitMQ on behalf of those users.

Here’s how it typically looks in action. Imagine a user, Alice, who exists in your corporate LDAP directory.

LDAP Authentication: Alice tries to connect to RabbitMQ management UI or a client application.
- The RabbitMQ rabbitmq_auth_backend_ldap plugin intercepts this.
- It queries your LDAP server (e.g., OpenLDAP, Active Directory) to verify Alice’s username and password.
- If successful, RabbitMQ creates a temporary session for Alice, mapping her LDAP distinguished name (DN) to a RabbitMQ user.
OAuth2 Authorization: Alice’s application needs to publish a message to a specific queue.
- The application first obtains an OAuth2 access token from your Identity Provider (IdP) – this could be Keycloak, Auth0, or even a custom OAuth2 server. This token is usually issued after Alice logs in to the application, and the application uses her LDAP credentials or a session cookie.
- When the application sends the message to RabbitMQ, it includes this OAuth2 access token in the Authorization: Bearer <token> HTTP header.
- You’ll have a plugin like rabbitmq_oauth2 or a custom authentication plugin that understands how to validate these tokens. This plugin will:
  - Check the token’s signature against your IdP’s public keys.
  - Verify the token’s expiration.
  - Extract user information (like sub for subject, or specific scopes) from the token’s payload.
  - Crucially, it needs to map the user identified by the token (e.g., Alice’s username or ID) to an existing RabbitMQ user. This is where the LDAP integration comes in.
Bridging LDAP and OAuth2: The magic happens when the OAuth2 plugin needs to know what permissions Alice has.
- The OAuth2 plugin, after validating the token, might extract Alice’s username from the sub claim.
- It then consults the LDAP backend (or a cached representation of it) to see if this user exists and what their group memberships are, or perhaps directly grants permissions based on claims within the OAuth2 token itself.
- RabbitMQ’s internal authorization logic then checks if the user (identified by the OAuth2 token and potentially enriched by LDAP data) has the necessary permissions (e.g., write on a specific exchange) to perform the requested action.

The core problem this solves is managing user identities and access control in a distributed system without hardcoding credentials or having a separate user database for RabbitMQ. LDAP provides a centralized identity source, and OAuth2 provides a standard, token-based mechanism for applications to securely access resources on behalf of users.

Here’s a typical rabbitmq.conf snippet for LDAP:

auth_backends.1 = rabbit_auth_backend_ldap
auth_backends.2 = rabbit_auth_backend_internal

# LDAP server details
ldap_servers.1.host = ldap.example.com
ldap_servers.1.port = 389
ldap_servers.1.vhost = /
# Use TLS if available
# ldap_servers.1.ssl = true
# ldap_servers.1.ssl_opts.cacertfile = /path/to/ca.crt

# How to bind to LDAP to perform searches
# Use an anonymous bind if your LDAP server allows it for searches
# ldap_servers.1.user =
# ldap_servers.1.password =

# Or use a service account
ldap_servers.1.user = cn=rabbitmq_user,ou=ServiceAccounts,dc=example,dc=com
ldap_servers.1.password = mysecretpassword

# How to find users
ldap_servers.1.user_dn_pattern = uid={0},ou=users,dc=example,dc=com

# How to find groups and their members
ldap_servers.1.group_dn_pattern = cn={0},ou=groups,dc=example,dc=com
ldap_servers.1.group_search_base = ou=groups,dc=example,dc=com

For OAuth2, you’d typically configure it via the management UI or programmatically, often pointing to your IdP’s introspection endpoint or JWKS URI.

The most surprising thing about this setup is how the LDAP backend often acts as a secondary source of truth for authorization, even when OAuth2 is the primary authentication mechanism. The OAuth2 plugin validates the token and extracts a user identifier, but then RabbitMQ’s authorization logic might still need to consult the LDAP backend to determine the full set of permissions associated with that user, especially if permissions are managed via LDAP group memberships. This means the LDAP configuration is critical not just for initial login but for ongoing access control.

The next concept you’ll typically run into is managing RabbitMQ permissions (vhosts, exchanges, queues, topics) granularly, and how these map to the users and groups discovered via LDAP and authenticated via OAuth2.