Authentication for protocols without SASL (MQTT 3.1.1, CoAP): configurable backends, port-based SASL, or extra connection metadata

[arvindh123]

RabbitMQ series

4.1.x

Operating system (distribution) used

Docker

How is RabbitMQ deployed?

Community Docker image

What would you like to suggest for a future version of RabbitMQ?

In short:
MQTT clients don’t use SASL — they directly call rabbit_access_control:check_user_login
@

rabbitmq-server/deps/rabbitmq_mqtt/src/rabbit_mqtt_processor.erl

Lines 1096 to 1110 in 6ae0246

	check_user_login(VHost, Username, Password, ClientId, PeerIp, ConnName) ->
	AuthProps = [{vhost, VHost},
	{client_id, ClientId},
	{password, Password}],
	case rabbit_access_control:check_user_login(Username, AuthProps) of
	{ok, User = #user{username = Username1}} ->
	notify_auth_result(user_authentication_success, Username1, ConnName),
	{ok, User};
	{refused, Username, Msg, Args} ->
	?LOG_ERROR("MQTT connection failed: access refused for user '~s':" ++ Msg,
	[Username | Args]),
	notify_auth_result(user_authentication_failure, Username, ConnName),
	auth_attempt_failed(PeerIp, Username),
	{error, ?RC_BAD_USER_NAME_OR_PASSWORD}
	end.

.
Because of this, it would be helpful if the MQTT plugin provided options for configurable authentication backends. Possible approaches include:

• Configurable backends per protocol/plugin
• Port + SASL configuration during plugin setup (so each port enforces a specific auth mechanism)
• Passing extra connection metadata (client IP/port, server IP/port, protocol, version, etc.) to the auth backend, allowing custom logic

In detail:
In SUPER_DUPPER_APP, RabbitMQ is used as the core message bus.

• Clients (from the public internet) connect via AMQP, MQTT (plugin), or even other protocols (e.g. CoAP via a custom plugin). Their credentials are stored in SUPER_DUPPER_APP.
• Internal services (running alongside RabbitMQ in Kubernetes) communicate over AMQP/Streams only, and use RabbitMQ’s internal auth. These services have full access and don’t use MQTT/CoAP.

So the challenge is: how to distinguish external clients from internal services?

To solve this, I created three new auth mechanisms:

• SUPER_DUPPER_APP → plain (non-TLS and TLS, username/password)
• SUPER_DUPPER_APP_MTLS → mutual TLS, no username/password

Configured by port:

• AMQP:

  • 5672 → SUPER_DUPPER_APP (plain / TLS, username+password)
  • 5671 → SUPER_DUPPER_APP_MTLS (mTLS only)

• MQTT:

  • 1883 → SUPER_DUPPER_APP (plain, username+password)
  • 8883 → SUPER_DUPPER_APP (TLS, username+password)
  • 8884 → SUPER_DUPPER_APP_MTLS (mTLS only)

The issue: unlike AMQP, MQTT has no SASL negotiation, so all MQTT connections go through check_user_login/6 without a way to select the right mechanism.
rabbit_access_control:check_user_login.

Proposing solution:

1.) Add a way for the MQTT plugin to have its own configurable auth_backends.

2.) Or, as @marchhare_54339 suggested, extend rabbit_access_control so it receives extra connection metadata (client IP/port, server IP/port, protocol, version). Then the backend can make the right decision without per-protocol backends.

3.) Provide a configuration option to associate each MQTT port with a specific SASL authentication mechanism, ensuring clients on that port use the intended auth method.

[arvindh123]

Port-based SASL configuration as a solution for non-SASL protocols (e.g., MQTT 3.1.1)

One approach I’d like to propose is “Port + SASL configuration during plugin setup”. This could simplify authentication for protocols that don’t support SASL, like MQTT 3.1.1, and potentially remove the need for configurable auth_backends for those cases.

The idea is that each Auth Mechanism would forward authentication requests to the appropriate backend:

• For example, the PLAIN auth mechanism calls its respective backend (rabbit_access_control), which in turn can query internal or external backends (e.g., a database).
• In this model, the Auth Mechanism itself is distinct — it’s not an internal client.
• Instead of using the external database like normal clients, it would follow its own mechanism and forward requests to the correct backend.

Extending SASL mechanism names
Currently, SASL auth mechanisms like PLAIN, AMQPPLAIN, and EXTERNAL do not indicate which application the client belongs to.

We can extend the SASL mechanism name to specify the target application for authentication. For example:

• SUPER_DUPPER_APP → authenticates clients belonging to the SUPER_DUPPER_APP application
• SUPER_DUPPER_APP_TLS → authenticates clients from the same app over TLS
• SUPER_DUPPER_APP_MTLS → authenticates clients from the same app using mTLS

With this approach, a single RabbitMQ instance can handle authentication for multiple applications, each using its own SASL mechanism.

This design provides a natural flow for handling multiple protocols, ports, and applications, ensuring that MQTT 3.1.1 clients can authenticate correctly while keeping the system flexible for other protocols.

[ansd]

FTR, the original discussion started in https://discord.com/channels/1092487794984755311/1092487889893466174/1419630950371033201

Pasting my answers here:

I can see how it can make sense to require different authentication mechanisms for clients that connect over the public internet (e.g. where you would want to require a client certificate) vs. clients that connect from some trusted internal corporate IP address (e.g. username+password authentication is good enough). In this case we talk about different auth backends for the different client source IP addresses (or maybe for different usernames).

But I still don’t see why you would want different authentication or authorisation taking place for different protocols. Surely, whether a given username connects over MQTT or AMQP or the Streams protocol from the same host, that username should be authenticated in exactly the same way? And surely if the same username publishes from the same host to a certain topic, you would want exactly the same topic authorisation to take place independent of whether that user connected over MQTT or AMQP?

So, it’s important to be precise what exactly you want a different auth backend for. It would makes sense to me for different usernames or vhosts or IP addresses, but it doesn’t make sense to me for just different protocols.

MQTT 5.0 supports SASL, it's just not supported (yet) in RabbitMQ. In my vision, RabbitMQ should support SASL (including the MQTT AUTH packet) for MQTT 5.0 in the future. This will streamline how authentication works in other protocols supported by RabbitMQ because SASL is already supported in AMQP 1.0, AMQP 0.9.1, and the RabbitMQ streams protocol today.

Passing some additional metadata to the different auth backends, like the socket or IP address is fine to me too, if that's missing today. Note that RabbitMQ already provides the client address to the check_vhost_access callback (see https://github.com/rabbitmq/rabbitmq-server/blob/a09383d1e5707a7d969c5b7dbbf036715b563f6f/deps/rabbit/src/rabbit_access_control.erl#L279C1-L310)