OAuth 2: some IDPs do not support the aud field. Is there a way to make RabbitMQ use an alternative field?

[barosch47]

RabbitMQ series

4.1.x

Operating system (distribution) used

linux

How is RabbitMQ deployed?

Kubernetes Operator(s) from Team RabbitMQ

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

Hey everyone, not sure if this was the right kind of discussion type, if not I am sorry.

I have now faced 2 idps which are having troubles to provide an "aud" field. They usually can very easy provide a custom field lets say "aud_id".
Without the aud field we can't use multiple resource servers If I am not mistaken.

What do you think about having something like _additional_aud_key. Similar to how it is for the scope field. Or a way of remapping it to a different key.

Thanks.

[michaelklishin]

@barosch47 should we guess what those IDPs are? We are very bad at mind reading on this team.

aud is a registered (standard) field in RFC 7519 that describes the JWT structure.

No, there is no alternative to aud.

We already support five IDPs and we are one of the very few tools in the industry that can even support two IDPs. I don't see why it would be really necessary to support such IDPs that deviate from standards.

Unless @MarcialRosales feels very generous, I'd say this is a kind of feature users should pay for or contribute. 99.9% of users are not going to need it.

[michaelklishin]

To conclude: unless someone contributes such a feature or a paying user asks for it, we won't spend any time on support for such IDPs.

Here are the relevant functions. The change won't take a lot of effort but please consult with the core team about a reasonable rabbitmq.conf key name for the setting.

[MarcialRosales]

Just to add to what @michaelklishin said. Can you please share which Idp uses a different claim to declare the audiences? and can you also please share what names those Idps chose for the aud claim? We could add it to the backlog after investigating what those Idps are.

[barosch47]

Hey,

thank you both very much for your answers.
I can understand that you will only spent time on such a feature when payed or self contributed. Options we can of course think about and maybe come back to you via Mail/Discord.

To answer your questions:

I can't tell a lot since we don't manage the IDPs ourself, so I am already sorry.

But one of the IDP is actually AWS Cognito and their AccessTokens, which does not even include an aud key, adding one as a custom claim gets omitted so no luck there.
Their idToken has an audience field but thats not what is being used. Also I can't tell if the aud is a constant value for all clients/users.

The other one, I don't know the name sadly, has the same issue that each client has a different aud (value).

So after seeing two different IDPs struggling with a constant aud (value) but being able to add custom keys easy and knowing that custom keys in rabbitMQ are supported e.g. additional scope key or preferred_username_claims I thought maybe having it for aud would be nice and reached out.

Again thank you very much, I will see what our next steps are and maybe reach out.

[michaelklishin]

@barosch47 I have reached out to the RabbitMQ R&D team at AWS to see if they would be interested in contributing this feature after confirming that AWS Cognito indeed behaves that way.

[MarcialRosales]

In any case, there appears to be a way to customize access tokens in AWS Cognito: https://aws.amazon.com/blogs/security/how-to-customize-access-tokens-in-amazon-cognito-user-pools/

[barosch47]

Yes, this is used to add custom scopes for the scopes-to-permission translation. But when they tried to add an aud key it seems to not work, is what I was told. Maybe your R&D will find out more.