AWS Big Data Blog
Authentication and authorization options for Amazon MQ for RabbitMQ
Managing authentication for message brokers at scale is complex: credentials sprawl, audit requirements, and integration with existing identity providers create operational overhead. The default approach of creating RabbitMQ users with static usernames and passwords works for getting started, but it quickly becomes a liability at scale. Credentials must be distributed securely, rotated regularly, and revoked promptly when team members change roles or leave the organization. For regulated industries, auditors want to see that your messaging infrastructure enforces the same identity and access controls as the rest of your environment.
Different organizations have different identity infrastructures. Some manage users through Active Directory. Others have standardized on OAuth 2.0. Platform teams building on AWS want to use AWS Identity and Access Management (IAM) roles and policies they understand. Security-conscious environments might require certificate-based authentication where no passwords are transmitted over the network at all.
Amazon MQ for RabbitMQ supports multiple authentication and authorization methods, so you can connect your broker to the identity infrastructure you already use. This post introduces the available options and helps you choose the right one for your use case.
Authentication methods at a glance
Amazon MQ for RabbitMQ supports the following authentication and authorization methods:
| Method | Credential type | User management | Recommended for |
| Simple credentials | Username / password | Broker-local | Getting started, development environments |
| OAuth 2.0 | Bearer tokens from external identity provider | External identity provider | Workloads that need short-lived tokens from a third-party identity provider |
| IAM authentication | Short-lived JSON Web Tokens (JWTs) from AWS Security Token Service (AWS STS) | IAM | AWS-native workloads, multi-tenant isolation, credential-free authentication |
| LDAP | Directory credentials | Active Directory or LDAP server | Organizations with existing directory services |
| HTTP-based auth backend | Username / password validated by external server | External HTTP server | Custom auth logic, centralized user management across brokers |
| SSL certificate authentication | Certificate only (passwordless) | Broker-local (username extracted from cert) | Eliminating passwords entirely with certificate-only identity |
| Mutual TLS (mTLS) | Certificate and username/password | Broker-local | Adding transport-layer certificate verification to existing credential-based auth |
Choosing the right method
The right choice depends on your existing identity infrastructure, security requirements, and operational preferences.
Simple credentials
The default method. You create RabbitMQ users with usernames and passwords directly on the broker. This is a straightforward way to get started, but it requires you to manage credentials manually. Choose this for development, testing, or small-scale deployments where credential management overhead is acceptable.
OAuth 2.0
Clients obtain short-lived tokens from any OAuth 2.0-compatible identity provider and present them to the broker as bearer tokens. Choose this when you have an existing identity provider (other than IAM) that issues tokens for your applications, and you want automatic token expiration without managing broker-local credentials.
IAM authentication
IAM serves as an identity provider. Client applications use their IAM credentials to obtain a short-lived JWT from AWS Security Token Service (AWS STS) and present it as a bearer token. IAM policies control which roles can obtain tokens. RabbitMQ scope aliases on the broker map each role’s Amazon Resource Name (ARN) to specific resource permissions (read, write, configure, and administrator). AWS CloudTrail logs every token issuance for auditing. Choose this when your workloads run on AWS compute services with IAM roles, and you want credential-free, IAM-native authentication with broker-level authorization.
LDAP
Connect your broker to an existing directory service such as Active Directory. Users authenticate with their directory credentials, and RabbitMQ permissions map to LDAP group memberships. Choose this when your organization already manages users and groups through a directory service, and you want to apply existing password policies and group-based access control to broker access.
HTTP-based auth backend
Delegates authentication and authorization decisions to a custom HTTPS server. The broker sends HTTP requests to your server for user validation, virtual host access, resource permissions, and topic permissions. Choose this when you need custom authentication logic, want to centralize user management across multiple brokers, or need to integrate with an identity system that doesn’t support OAuth 2.0 or LDAP natively.
SSL certificate authentication
Removes passwords entirely. The broker uses the EXTERNAL Simple Authentication and Security Layer (SASL) mechanism to extract the client’s identity directly from the X.509 certificate (for example, from the Common Name field) and uses it as the RabbitMQ username. With this method, your application doesn’t transmit credentials over the network. Choose this when your security policy requires passwordless authentication, and you manage client identities through a public key infrastructure (PKI).
Mutual TLS (mTLS)
Adds certificate verification on top of existing username/password authentication. During the TLS handshake, the client validates the broker’s certificate and the broker validates the client’s certificate, then the client provides a username and password at the application layer. This gives you two-factor security: something you have (the certificate) plus something you know (the password). Choose this when compliance frameworks require mutual authentication, but you want to retain your existing username/password authentication flow.
Conclusion
Amazon MQ for RabbitMQ version 4 supports seven authentication and authorization methods. With these methods, you can align your message broker security with your existing identity infrastructure. Your organization might standardize on IAM, manage identities through Active Directory, federate access through a third-party identity providers like Okta or Microsoft Entra ID, or rely on PKI for certificate-based trust. In each case, you can eliminate the operational overhead of managing static credentials at scale.
Choose your implementation path:
- Certificate-based security: Follow Part 1: Mutual TLS and SSL Certificate Authentication to implement passwordless broker access using certificates.
- Enterprise identity integration: Follow Part 2: OAuth 2.0, LDAP, and HTTP Authentication to connect your existing identity provider and use your current user directories.
- AWS-native access control: Follow Part 3: IAM Authentication to use IAM-native access control.