OAuth 2.0 configuration for LavinMQ from the CloudAMQP console and API

We're happy to announce that OAuth 2.0 configuration is now available for LavinMQ in the CloudAMQP console and API. You can set up and manage OAuth 2.0 authentication for your LavinMQ clusters directly, without requiring assistance from our support team.

What is OAuth 2.0 and why does it matter?

OAuth 2.0 is an industry-standard protocol for authentication and authorization, that enables secure access to resources without credential sharing. Using OAuth 2.0 for your LavinMQ clusters adds another layer of security through JWT token-based authentication, allows for integration with identity providers, and makes it easier to control access for team members and applications. The configuration supports any OpenID Connect (OIDC) compliant identity provider, such as UAA, Keycloak, Auth0, Azure, and Okta.

What's supported in LavinMQ 2.7

OAuth 2.0 is available on dedicated LavinMQ instances running LavinMQ 2.7 or later.

In this first release, OAuth 2.0 authentication applies to:

• AMQP connections
• MQTT connections
• The HTTP API

The LavinMQ management UI still uses basic authentication and does not support OAuth 2.0 / SSO login in this release. We plan to extend OAuth 2.0 coverage to the management UI in a future LavinMQ release.

How to configure OAuth 2.0 for your LavinMQ clusters

To configure OAuth 2.0 for your cluster, follow these steps. For full reference details on every field and value, see the OAuth 2.0 for LavinMQ documentation.

• Set up an OAuth 2.0 application on your identity provider
  • The exact steps differ between providers, but generally you will:
  • Create an application/client and/or API for LavinMQ
  • Note the issuer URL (the OIDC discovery endpoint) and, if your provider uses it, the audience value that represents LavinMQ as a resource server
• In the CloudAMQP console, open your LavinMQ instance and go to OAuth 2.0 configuration
  1. Enter the URL of your OAuth 2.0 authorization server in the issuer field. This is required and must be HTTPS.
  2. Optionally set resource_server_id to the identifier that represents your LavinMQ instance as an OAuth 2.0 resource server. This is used as the default scope prefix.
  3. Optionally set audience if your identity provider requires it (for example Auth0). Do not set it when using Azure/Entra v2 endpoints.
  4. verify_aud is enabled by default. Leave it on for production instances; disable it only for test or development.
  5. Fine-tune with the remaining fields as needed: preferred_username_claims (claims to derive the username from), additional_scopes_keys (extra JWT claim keys to pull scopes from), scope_prefix (custom prefix if it differs from resource_server_id ), and jwks_cache_ttl (how long signing keys are cached, in seconds; 0–86400).
• Configure scopes in your OAuth 2.0 provider
  • Configure scopes that match LavinMQ's permission model:
  • configure:vhost/resource - Configure permissions
  • read:vhost/resource - Read permissions
  • write:vhost/resource - Write permissions
  • Assign these scopes to the users, clients, or roles that should connect to LavinMQ over AMQP, MQTT, or the HTTP API.

Save your changes in the console. After saving, a broker restart is required for the changes to take effect. The console will indicate when a restart is needed.

The same configuration is also available through the CloudAMQP API, so you can automate provisioning and keep OAuth 2.0 settings in sync across environments alongside the rest of your infrastructure-as-code. The API fields and accepted values are documented in the OAuth 2.0 for LavinMQ guide.

If you're experiencing difficulties with setting up or running OAuth 2.0, please reach out to support@cloudamqp.com for assistance. Our support team is ready to help you.

Share your feedback

This self-service configuration is part of our effort to expand the level of self control for your cluster. We'd love to hear your feedback. Share your thoughts and suggestions with us on contact@cloudamqp.com