Web STOMP subsciptions continue working even if access token has expired

[thomas-rudlof-bl]

Describe the bug

I use the web stomp plugin together with the OAuth 2.0 plugin.
I authenticate the connection of my web stomp client to ws://localhost:15674/ws by setting the user to null and the password to the access token.
The access token will expire after 15s.
While sending a new message fails right after the token has expired, receiving new messages works for a very long time after token expiration.

Reproduction steps

1. install and configure web-stomp and oauth-2.0 plugin
2. create a topic exchange foo (e.g. via the RabbitMQ admin web UI)
3. create a web application, that gets a access token that will expire soon (e.g. in 15s)
4. create a stomp client (e.g. by using https://raw.githubusercontent.com/jmesnil/stomp-websocket/master/lib/stomp.js)
5. use null as user and the access token as password and connect to the RabbitMQ web stomp endpoint
6. subscribe to the destination /exchange/foo/key.#
7. start the web application
8. in the RabbitMQ web UI start sending messages to the exchange foo with routing key key.4

The web application continues receiving messages even after the token has expired.

Expected behavior

As soon as the token expires, the application should not receive any messages any longer.

Additional context

No response

[michaelklishin]

There are gaps in the reproduction steps where we would have to guess. We do not guess in this community.

What version of RabbitMQ was used?

What exactly does "configure" mean? Please provide your actual configuration (with token values and usernames modified or edited out, of course)?

How do you observe that the token indeed has expired?

[thomas-rudlof-bl]

RabbitMQ version: 3.11.7

rabbitmq.conf ======================================================

Enable debug logging

log.file.level = debug
log.console = true
log.console.level = debug

Management

management.enable_uaa = false
management.disable_basic_auth = false

OAuth2 configuration: https://www.rabbitmq.com/oauth2.html

auth_backends.1 = rabbit_auth_backend_oauth2 # JWT based AuthN for services
auth_backends.2 = internal # basic AuthN needed for management portal

auth_oauth2.resource_server_id = rabbitmq
auth_oauth2.jwks_url = https://iam:4444/.well-known/jwks.json
auth_oauth2.https.peer_verification = verify_none
auth_oauth2.verify_aud = false

auth_oauth2.algorithms.1 = RS256

TLS configuration

listeners.ssl.default = 5671

ssl_options.cacertfile = /etc/rabbitmq/certs/rootCA.pem
ssl_options.certfile = /etc/rabbitmq/certs/cert.pem
ssl_options.keyfile = /etc/rabbitmq/certs/key.pem
ssl_options.verify = verify_none
ssl_options.fail_if_no_peer_cert = false

disables non-TLS listeners, only TLS-enabled clients will be able to connect

listeners.tcp = none

advanced.config====================================================
[
{rabbitmq_auth_backend_oauth2, [{extra_scopes_source, <<"scp">>}]}
].

How did I observe that the token expired:

1. In the token response from the Ory Hydra, the token expiration was reported as 14s
2. In the token itself, iat and exp claims reported the correct values
3. Using the same token for sending messages stopped working right after token expiration - so in this case RabbitMQ detected the expiration as expected
4. Using the same token for creating new connections stopped working right after token expiration - so in this case RabbitMQ detected the expiration as expected.

[michaelklishin]

Looks like the expectation here is that RabbitMQ will re-evaluate token expiration for every operation. For some protocols, this is the case. For Web STOMP, the token is only verified when the client subscribes.

Token expiration for existing clients is a fairly complicated topic. Other protocols support
a way to provide an updated token to the server after the application renews it. In STOMP, there
is no such operation. Yes, STOMP is extensible but we do not maintain STOMP clients.

So for STOMP, these are the limitations for now, and they likely won't change soon: new connections from a client with an expiring token will fail, and so will new subscriptions. But existing subscriptions will not be cancelled, and neither will their connections be affected.

[michaelklishin]

As a workaround, you can close all Web STOMP connections every N hours or days. That will make sure that clients with expired tokens won't be able to do much.

In theory this could be something that the plugin does, periodically tell all connections to re-evaluate their token and self-terminate if it's expired. Doing so with a large number of connections can be fairly expensive.

[michaelklishin]

I have filed #8295