Authentication over AMQP RPC
Switch branches/tags
rabbitmq_v3_7_0_milestone18 rabbitmq_v3_7_0_milestone17 rabbitmq_v3_7_0_milestone16 rabbitmq_v3_7_0_milestone15 rabbitmq_v3_7_0_milestone14 rabbitmq_v3_7_0_milestone13 rabbitmq_v3_7_0_milestone12 rabbitmq_v3_7_0_milestone11 rabbitmq_v3_7_0_milestone10 rabbitmq_v3_7_0_milestone9 rabbitmq_v3_7_0_milestone8 rabbitmq_v3_7_0_milestone7 rabbitmq_v3_7_0_milestone6 rabbitmq_v3_7_0_milestone5 rabbitmq_v3_7_0_milestone4 rabbitmq_v3_7_0_milestone3 rabbitmq_v3_7_0_milestone2 rabbitmq_v3_7_0_milestone1 rabbitmq_v3_6_14 rabbitmq_v3_6_13 rabbitmq_v3_6_13_rc2 rabbitmq_v3_6_13_rc1 rabbitmq_v3_6_13_milestone1 rabbitmq_v3_6_12 rabbitmq_v3_6_12_rc3 rabbitmq_v3_6_12_rc2 rabbitmq_v3_6_12_rc1 rabbitmq_v3_6_11 rabbitmq_v3_6_11_rc3 rabbitmq_v3_6_11_rc2 rabbitmq_v3_6_11_rc1 rabbitmq_v3_6_11_milestone5 rabbitmq_v3_6_11_milestone4 rabbitmq_v3_6_11_milestone3 rabbitmq_v3_6_11_milestone2 rabbitmq_v3_6_11_milestone1 rabbitmq_v3_6_10 rabbitmq_v3_6_10_rc2 rabbitmq_v3_6_10_rc1 rabbitmq_v3_6_10_milestone4 rabbitmq_v3_6_10_milestone3 rabbitmq_v3_6_10_milestone2 rabbitmq_v3_6_10_milestone1 rabbitmq_v3_6_9 rabbitmq_v3_6_8 rabbitmq_v3_6_7 rabbitmq_v3_6_7_rc3 rabbitmq_v3_6_7_rc2 rabbitmq_v3_6_7_rc1 rabbitmq_v3_6_7_milestone6 rabbitmq_v3_6_7_milestone5 rabbitmq_v3_6_7_milestone4 rabbitmq_v3_6_7_milestone3 rabbitmq_v3_6_7_milestone2 rabbitmq_v3_6_7_milestone1 rabbitmq_v3_6_6 rabbitmq_v3_6_6_rc2 rabbitmq_v3_6_6_rc1 rabbitmq_v3_6_6_milestone5 rabbitmq_v3_6_6_milestone4 rabbitmq_v3_6_6_milestone3 rabbitmq_v3_6_6_milestone2 rabbitmq_v3_6_6_milestone1 rabbitmq_v3_6_5 rabbitmq_v3_6_5_milestone2 rabbitmq_v3_6_5_milestone1 rabbitmq_v3_6_4 rabbitmq_v3_6_4_rc1 rabbitmq_v3_6_4_milestone2 rabbitmq_v3_6_4_milestone1 rabbitmq_v3_6_3 rabbitmq_v3_6_3_rc3 rabbitmq_v3_6_3_rc2 rabbitmq_v3_6_3_rc1 rabbitmq_v3_6_3_milestone2 rabbitmq_v3_6_3_milestone1 rabbitmq_v3_6_2 rabbitmq_v3_6_2_rc4 rabbitmq_v3_6_2_rc3 rabbitmq_v3_6_2_rc2 rabbitmq_v3_6_2_rc1 rabbitmq_v3_6_2_milestone5 rabbitmq_v3_6_2_milestone4 rabbitmq_v3_6_2_milestone3 rabbitmq_v3_6_2_milestone2 rabbitmq_v3_6_2_milestone1 rabbitmq_v3_6_1 rabbitmq_v3_6_1_rc2 rabbitmq_v3_6_1_rc1 rabbitmq_v3_6_0 rabbitmq_v3_6_0_rc3 rabbitmq_v3_6_0_rc2
Nothing to show
Clone or download


This plugin provides the ability for your RabbitMQ server to perform authentication (determining who can log in) and authorisation (determining what permissions they have) by connecting to an authorisation server over RPC-over-AMQP.

The plugin requires RabbitMQ 3.2.x or a later version.

Note: this is a rarely used plugin, and could be made rather more robust.


You can download a pre-built binary of this plugin from the Community Plugins page.


You can build and install it like any other plugin (see the plugin development guide).

This plugin depends on the Erlang client.

Enabling the plugin

To enable the plugin, set the value of the auth_backends configuration item for the rabbit application to include rabbit_auth_backend_amqp. auth_backends is a list of authentication providers to try in order.

Obviously your authentication server cannot vouch for itself, so you'll need another backend with at least one user in it. You should probably use the internal database:

  [{auth_backends, [rabbit_auth_backend_internal, rabbit_auth_backend_amqp]}]

Configuring the plugin

You need to configure the plugin to know which exchange to publish authentication requests to.

Below is a minimal rabbitmq.conf example (currently only in master):

auth_backends.1 = internal
auth_backends.2 = amqp

auth_amqp.username = guest
auth_amqp.vhost    = / = authentication

Or, in the classic config format (rabbitmq.config, prior to 3.7.0) or advanced.config:

  {rabbit, [{auth_backends, [rabbit_auth_backend_internal,
   [{username, <<"guest">>},
    {vhost,    <<"/">>},
    {exchange, <<"authentication">>}]}

Authentication requests will be packed into the headers of incoming messages. There are four types of request: login, check_vhost, check_resource and check_topic. Responses should be returned in the message body. Responses to login requests should be "refused" if login is unsuccessful or a comma-separated list of tags for the user if login is successful. Responses to the other types should be the words "allow" or "deny".

It will probably be a good idea to look at the Java example for more details.

You can also specify a timeout config item. This should be an integer number of milliseconds to wait for a response from the RPC server, or infinity to wait forever (the default). If the RPC server does not respond in time, the request for access is denied.

Example App (in Java)

In examples/rabbitmq-auth-backend-java there's a Java based authentication server framework based around the com.rabbitmq.authbackend.AuthBackend interface with a very trivial implementation in com.rabbitmq.authbackend.examples (which will authenticate "simon" / "simon"). This implementation also checks the routing key starts by a when publishing to a topic exchange or consuming from a topic. (a.k.a. topic authorisation).