Support OAuth2 Opaque tokens

[MarcialRosales]

Is your feature request related to a problem? Please describe.

Google OAuth2 Authorization Server issues OAuth 2.0 Opaque Access Tokens. RabbitMQ expects digitally signed JWT tokens. Therefore when you try to authenticate with Google opaque access token, either via the management ui or via one of its messaging protocols, RabbitMQ rejects it indicating that it is an invalid token.

This means that RabbitMQ does not support Google as an Authorization Server.

Describe the solution you'd like

Use Google as an OAuth 2.0 Authorization server like Keycloak or Azure, at least, with the management ui.

RabbitMQ would need to use an endpoint called Token Introspection (/tokeninfo) to validate and convert an opaque token into a JWT token so that RabbitMQ can extract the scope claim and check permissions accordingly.

RabbitMQ can add support for Opaque tokens to the management ui only or to the management ui and every messaging protocol. This feature request was originally requested for the management ui.

When a successful authenticated user is redirected back to the management ui (via the authorization code with PKCE flow), it carries an Id Token and an opaque access token. RabbitMQ has to callback Google's /tokeninfo endpoint to convert the opaque access token to a JWT access token. And this token is what the management ui keeps in its local cache and also what it passes to RabbitMQ to check permissions. As long as users do not use google opaque tokens to access the messaging protocols, this is all we need to do to support opaque tokens.

However, if opaque tokens are also used to authenticate to the messaging protocols, RabbitMQ would have to make a callback to the configured Introspection endpoint to get back a JWT token.

In terms of configuration, RabbitMQ needs an additional configuration entry called introspection_token_url.

Describe alternatives you've considered

An alternative could be, but it has not been tested it yet, to use OAuth2 proxy in between Google and RabbitMQ. If this alternative worked, the feature request described here would not be necessary. Although for the users, it means an extra network hop and the burden of having to configure and maintain another software if they are not already using Oauth2 proxy.

Additional context

No response