OAuth2 with Azure Entra ID B2C uses a fixed global aud field, which violates RabbitMQ OAuth 2 backend assumptions

[norbert-ka]

Describe the bug

We are trying to use the OAuth2-Backend with Azure Entra ID for the authentication and authorization against the management-ui.

We used the documentation under https://www.rabbitmq.com/docs/oauth2-examples-entra-id#configure-rabbitmq-to-use-entra-id-as-oauth-20-authentication-backend to get the configuration right.

The only thing we needed to change was the URI of our exposed API. In Entra ID B2C the URI of the API is made up in the following way: https://{tenantname}.onmicrosoft.com/{Application(client) ID}/{api-name}.

With rabbitmq as {api-name} we use the following configuration:

management.oauth_enabled = true
management.oauth_client_id = {Application(client) ID}
management.oauth_scopes = openid profile https://tenantname.onmicrosoft.com/{Application(client) ID}/rabbitmq

auth_oauth2.resource_server_id = {Application(client) ID}
auth_oauth2.additional_scopes_key = roles
auth_oauth2.issuer = https://login.microsoftonline.com/{Directory (tenant) ID}/v2.0

We this configuration we can login using Azure, but back in the managment-ui get an error 'Authorization failed'. A look into the logs shows that validation of the token in the rabbit-authbackend-oauth2 module fails with a {error,no_matching_aud_found}. Which results from a part of code in rabbit_oauth2_resource_serve.find_audience where in the list of values in the aud-claim an exact match with the resourece-server-id is searched.

A look into the access token provided by Azure finds the aud-caim to look like this:

"aud" : "https://{tenant-name}.onmicrosoft.com/{Application(client) ID}"

Since the OAuth-Backend expects the aud-claim to exactly match the resource-server-id ({Appplication(Client) ID}), the lookup of an matching aud fails.

Azure Documentation states that Entra ID will use the globally unique Application ID URI as the value of the audience claim, when using an API. So this is the expected behaviour from Entra ID and RabbitMQ should be able to cope with it.

Is there any way around this problem other than setting auth_oauth2.verify_aud=false?

Reproduction steps

1. Setup the Azure Entra ID and RabbitMQ configuration as describe in We used the documentation under https://www.rabbitmq.com/docs/oauth2-examples-entra-id#configure-rabbitmq-to-use-entra-id-as-oauth-20-authentication-backend , with the exception of the URI for the API as described above.
2. Open RabbitMQ-Management-UI and login using Azure Entra-ID
3. Management-UI reports Authorization failed and {error,no_matching_aud_found} is logged in the backend

Expected behavior

RabbitMQ should accept the aud-claim as it is given by Entra ID or give an option to configure an expected aud-claim other than the resource-server-id.

Additional context

No response

[michaelklishin]

@norbert-ka you haven't even shared any logs, how is this a bug report? Please use discussions for questions.

As our community support policy clearly states, we will not troubleshoot OAuth 2 for non-paying users.

I don't see why "RabbitMQ should be able to cope with it", Entra keeps deviating from the OAuth 2 standards, or at least common implementation choices and practices, and RabbitMQ supports five different IDPs, including Entra (or at least its past versions) with known deployments.

auth_oauth2.verify_aud has been around for close to three years.

[MarcialRosales]

RabbitMQ documentation clearly states that it expects the aud field to match the configured resource_server_id, in your case {Application(client) ID}. However, Azure is returning a different value as you point out. RabbitMQ cannot do much about it. You can disable validation of audience.