Enabling OAuth2 on Management UI

[szuwarek80]

I use the rabbitmq:3.12-management docker image, and I am trying to configure it with the OAuth2.

My OAuth2 is home made server based on the oidc-provider.

My first step was to enable the OAuth2 on backend, I added the following lines to the config file

auth_backends.1 = rabbit_auth_backend_oauth2
auth_oauth2.resource_server_id = rabbitmq
auth_oauth2.jwks_url = https://iam:4000/oidc/jwks
auth_oauth2.verify_aud = false

and it works - great!
Having this configuration, on UI management side, I am using the empty user and jwt token generated with my OAuth2Server, and it also works - great!

The problem started when I tried to configure the OAuth2 on the Management side, so what I did is I added this to the config file:

management.oauth_enabled = true
management.oauth_client_id = rabbit_user_client
management.oauth_client_secret = rabbit_user_client
management.oauth_provider_url = https://localhost:4000/oidc

Authorization flow with PKCE is executed properly, the OAuth2 server generates the response containing the access_token and id_token. But after getting the response the UI Management query GET /api/whoami and it uses the access_token (while I believe it should use the id_token) as the bearer token in the authorization header - in result I have the error on the RabbitMQ server-side - Authentication using an OAuth 2/JWT token failed: provided token is invalid- and I cannot log in into the management.

If I query the GET /api/whoami with the id_token (generated during the authorization flow with PKCE started from the UI) the response is correct.
Why then the access_token is used, or maybe I understand it wrong ?

Thank you in advance

[lukebakken]

Thank you for re-posting your question here 😄

cc @MarcialRosales

[MarcialRosales]

access_token is what is always used to make access control decisions, not id_token. The latter only carry identities not permissions and/or scopes.

Can you share your access_token here? The encoded version. I think your access token is not fully compliant with what RabbitMQ expect. https://github.com/rabbitmq/rabbitmq-oauth2-tutorial#understanding-access-tokens-and-how-rabbitmq-uses-it

I will investigate tomorrow your oidc server which i was not aware of.

[szuwarek80]

My OIDC/OAuth2 server produces the following response when requesting the token:

{
access_token: 'IIlANsJ0WtYPkw2rJ6twf7wqsv6KCgY4nDOgBnt8oY1',
expires_in: 900,
id_token: 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik93RkJ0Z1ZoZktFMjN0cHlFX2tSRDJnYkR4MUh3UnYzZlNaMmRMZHExQmcifQ.eyJzdWIiOiI3NDI5MzdlNy1kNTkwLTRiMmEtOGM5Zi03NjgzNDMwYzI1MTIiLCJuYW1lIjoiYWRtaW4iLCJzY29wZSI6WyJvcGVuaWQiLCJwcm9maWxlIiwicmFiYml0bXEuKiIsInJhYmJpdG1xLnRhZzptYW5hZ2VtZW50Il0sImF0X2hhc2giOiJsMjJhNHlzZkh2NWtEWlQwdFcyWDF3IiwiYXVkIjoicmFiYml0X3VzZXJfY2xpZW50IiwiZXhwIjoxNzAwNTk2MDc5LCJpYXQiOjE3MDA1OTI0NzksImlzcyI6Imh0dHBzOi8vZG9ja2VyaG9zdC9vaWRjIn0.j1nHD0Pe-CrwqSDxESQ7iVOoG8SoW2V6sHg7yk9qdZx_cJDEH6f-qRTIA0APioW1pRjxgXy0hs3-v7hzxX5XdGopGouMrBQrxwD9SdOWDmGN7uaL0RfDpKqPyXgAn0F1IJbHhL8R8OAJ5C51eWYNHdelnfHv7Vjs3s9CWIiuB1c4Kj15fI0xvYf_dybdxVM48l5GzJrk-OjiZwTvW7fMjbmttRZZAqc-xj46n01CkB0L7znqwuW6k7Q1ekFQ1iNHs6S1stqBUYMydAXnXaosixTU5pzndLqNVBRGbIflYo9XjNCNH9tlIqf8xuF-jVBpK8wicUXBl0wIGNQBRuYlcQ',
refresh_token: undefined,
scope: 'openid profile rabbitmq.* rabbitmq.tag:management',
token_type: 'Bearer'
}

You can see that the access_token is the opaque token, while the id_token is the JWT token.
The access_token can be verified with the OIDC/OAuth2 server with the introspection endpoint, while the id_token can be decoded using the OIDC/OAuth2 server public key.

When configuring the OAuth2 backend in RabittMQ, I pointed where it can take from the public key :
auth_oauth2.jwks_url = https://iam:4000/oidc/jwks

When connecting programatically to RabbitMQ server with the amqp I send the id_token as password (leaving the user empty), and I believe the RabbitMQ decodes it with the given public key and from there it knows the scope which is translated to permissions.

I thought the frontend will work the same way -> just it will get the token itself followng the authorization with PKCE key.
If you say that on fronted the access_token is used (which is the opaque token) then it means that the RabbitMQ will perform the intropsection request to OIDC/OAuth2 server - I dont see it happens.

[MarcialRosales]

When you access amqp, you are actually passing the id_token .. As far as RabbitMQ is concerned, as long as the token conforms to the standard access token format which has a header and a payload and a sIgnature, and RabbitMQ can extract the scopes from the "scope" claim or from other claim you configured, then the token is accepted by RabbitMQ. In your case, the id_token contains the "scope" claim which is uncommon. Typically, id_token only contains identities and other information relative to the user.

The management plugin, via the PKCE authorization flow, receives an access_token and an id_token from the oauth provider. And RabbitMQ will only use the access_token because it is the token which carries the scopes / permissions. Not the id_token.

Can you please find out if you can configure your provider to issue JWT access-token not opaque ones? If you cannot, then I need to decide what it is best:
a) whether to support opaque tokens
b) configure management plugin to use the id_token instead of the access_token. But I cannot promise this one

Let me know what you think.

[szuwarek80]

Ok, understood. I overlooked the need to issue the access-token in JWT format. It looks like the library I use, supports issuing access-token in JWT format, I need to figure out how to do it.

[szuwarek80]

@MarcialRosales I managed to configure my provider to issue the JWT access-token and it works, thank you!

[MarcialRosales]

@szuwarek80 Great news ! I am glad for you that you got it working !! Thanks for posting your question here.