Best practice for authentication for Stomp Websockets users

[h0jeZvgoxFepBQ2C]

Hi,

right now I try to understand what the best authentication mechanism would be for my usecase:

I only use rabbitmq for stompjs websockets in streaming-mode (so only fanout more or less). I would like to prevent that all users have the same username/password, since I guess this would be a bit insecure, in case I want to switch to a bidirectional websocket connection?

Do I really have to create a new dedicated user for each website visitor (all users are logged in, no anonymous)?
This is really cumbersome, since I would have to delete the user afterwards in rabbitmq again, when the websession ends?

Or do I think about this completely wrong?
Any suggestions?
Thank you!

[michaelklishin]

Modern RabbitMQ versions support OAuth 2 (JWT) tokens, so that could be a better option for Web-based clients.

I'd say that every type of client needs its own credentials. I can imagine that in some cases a set of
shared credentials that's rotated between application deployments would work as well.

@MarcialRosales do you have an opinion?

[MarcialRosales]

Definitely OAuth 2 is very convenient for this use case. Because they do not need to manage users in RabbitMQ. The token can be obtained in two ways: The server-side delivers the token -less preferred option- or the client-side obtains its own token from the Authorization server -the preferred option and it is what the management plugin uses. However, the latter implies that end-users are ultimately authenticated against the Authorization server.

[h0jeZvgoxFepBQ2C]

I see. The problem is that we have multiple application servers (each customer gets one server) and only one rabbitmq server (and I would like to keep it that way). Is there any solution for this, since there is not one Oauth Server, but multiple with different users on each server?

[MarcialRosales]

If each customer has its own OAuth server and application server then this is what I suggest:

Each application server delivers a client-side configured with its OAuth server. The client-side uses the OAuth2 configuration to get a token for the user.

RabbitMQ is configured with as many signing keys as application servers exist. You can manage these keys at runtime without restarting rabbitmq (done via rabbitmqctl).

When a user connects to RabbitMQ via stomp/ws protocol, RabbitMQ validates the token found in the password field. It uses the signing key identified by the kid field in the token's header to validate the token's signature.

I would imagine a customer maps to a vhost in RabbitMQ. And therefore an OAuth server maps to a vhost and it should only grant scopes for that vhost.

[h0jeZvgoxFepBQ2C]

This sounds great, is this solution possible with the standard Oauth plugin for rabbitmq or do I have to create a plugin myself? Actually in the end I would even distribute the same signing key on all application servers (since its not a high security environment) and this would make it even easier.

[MarcialRosales]

I was referring to the standard OAuth plugin. RabbitMQ is only a small part of your whole solution.

With regards signing keys, you can either configure each them individually in RabbitMQ or instead configure the jwks_url that points to a web server that you can implement which returns a json with all your signing keys. This is up to you. Using jwks_url is very convenient if you rotate the signing keys very often. The alternative is connecting to RabbitMQ and calling the corresponding rabbitmqctl command to upload a new signing key.