Extract preferred_username_claims also from the id_token if present #12222
Description
Is your feature request related to a problem? Please describe.
RabbitMQ always extracts the user identity from a number of claim found in the access_token itself. The access_token is one of the attributes of a successful Access Token Response.
According to the OAuth2 spec, a successful Access Token Response should have, at least, an access_token attribute in addition to others such as expires_in. However, some OAuth Providers (like Auth0) may include an id_token to a successful Access Token Response. The id_token contains user’s authentication information such as username, user_ids, and others. When this happens, the access_token only contains the sub claim which commonly refers to an internal user identifier which the user cannot relate to.
This feature only applies to the Management UI plugin when the user is authenticated via the "Authorization Code or PKCE" Flow. In this flow, the Management UI requests an access token via the OpenID token endpoint. As explained above, Auth0 may reply not only with an access_token but with an id_token. In any other case, RabbitMQ expects an access token. For instance, when the Management U is configured with Idp-initiated-flow, the user has to come to the Management UI with an access token already obtained. Also when an application connects to any of the messaging protocols like AMQP, the user has to send an access token.
Describe the solution you'd like
RabbitMQ should look up auth_oauth2.preferred_username_claims in the access_token and also in the id_token if present in the Access Token Response.
Describe alternatives you've considered
So far, it is not worth implementing this feature for the complexity of the changes and the limited benefit that would return. It would only benefit users accessing management UI with tokens issued by Auth0.
The javascript code in the management ui that sends a http request to the backend's endpoint /whoami to authenticate and grant access to the management ui. It currently sends the access token in the Authorization header. It would need to send the id_token via another header. There are no official/standard http headers for that. Let's say, we create one called x-token-id (like in Grafana). The web module that calls into the authentication backends would have to extract not only the password from the Authorization header but also the username from the x-token-id. Then the oauth2 plugin would receive the id_token in the username field and the access_token in the password. The oauth2 plugin would need to handle two types of values as username. A plain string or a token. And finally, if it is a token , it has to validate its signature before using it to extract the username from it.