diff --git a/docs/management/index.md b/docs/management/index.md
index 9ac3ef844f..e2d7a8da8f 100644
--- a/docs/management/index.md
+++ b/docs/management/index.md
@@ -375,6 +375,7 @@ To configure OAuth 2.0 in the management UI you need a [minimum configuration](#
     * [Allow Basic and OAuth 2 authentication for management HTTP API](#allow-basic-auth-for-http-api)
     * [Allow Basic and OAuth 2 authentication for management UI](#allow-basic-auth-for-mgt-ui)
     * [Logging out of the management UI](#about-logout-workflow)
+    * [Configure extra parameters for authorization and token endpoints](#extra-endpoint-params)
     * [Special attention to CSP header `connect-src`](#csp-header)
     * [Identity-Provider initiated logon](#idp-initiated-logon)
     * [Support multiple OAuth 2.0 resources](#support-multiple-resources)
@@ -403,10 +404,14 @@ management.oauth_scopes = <SPACE-SEPARATED LIST OF SCOPES. See below>
 - `oauth_scopes` is a mandatory field which must be set at all times except in the case when OAuth providers automatically grant scopes associated to the `oauth_client_id`. `oauth_scopes` is a list of space-separated strings that indicate which permissions the application is requesting. Most OAuth providers only issue tokens with the scopes requested during the user authentication. RabbitMQ sends this field along with its `oauth_client_id` during the user authentication. If this field is not set, RabbitMQ defaults to `openid profile`.
 
 Given above configuration, when a user visits the management UI, the following two events take place:
-1. RabbitMQ uses the URL found in `auth_oauth2.issuer` followed by the path `/.well-known/openid-configuration` to download the OpenID Provider configuration. It contains information about other endpoints such as the `jwks_uri` (used to download the keys to validate the token's signature) or the `token_endpoint`.
+1. RabbitMQ uses the URL found in `auth_oauth2.issuer` to download the OpenID Provider configuration. Learn more in the [OAuth 2.0 guide](./oauth2#discovery-endpoint-params)
 
     :::warning
-    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and OAuth 2.0 authentication is disabled in the management UI.
+    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and the OAuth 2.0 authentication option will be disabled in the management UI
+    :::
+
+    :::tip
+    If you used to configure `management.oauth_metadata_url` because your provider did not use the standard OpenId Discovery endpoint's path, since RabbitMQ 4.1 you should instead configure the correct path as it is explained [here](./oauth2#discovery-endpoint-params).
     :::
 
 2. RabbitMQ displays a button with the label "Click here to login". When the user clicks on the button, the management UI initiates the OAuth 2.0 Authorization Code Flow, which redirects the user to the identity provider to authenticate and get a token.
@@ -505,6 +510,30 @@ RabbitMQ 3.13.1 and earlier versions require the [OpenId Connect Discovery endpo
 There are other two additional scenarios which can trigger a logout. One scenario occurs when the OAuth Token expires. Although RabbitMQ renews the token in the background before it expires, if the token expires, the user is logged out.
 The second scenario is when the management UI session exceeds the maximum allowed time configured on the [Login Session Timeout](#login-session-timeout).
 
+### Configure Extra URI Parameters for Authorization and Token Endpoints {#extra-endpoint-params}
+
+Some OAuth 2.0 providers require additional URI parameters to be included into the request sent to the **authorization endpoint** and/or to the **token endpoint**.
+These parameters are vendor- or IDP installation-specific. The Management UI already sends all the parameters required by the OAuth 2.0 Authorization Code flow.
+
+In the followingexample an extra URI parameter called `audience` is added for both the **authorization** and **token** endpoints:
+
+```ini
+management.oauth_authorization_endpoint_params.audience = some-audience-id
+
+management.oauth_token_endpoint_params.audience = some-audience-id
+```
+
+Multiple parameters can be configured like so:
+
+```ini
+management.oauth_authorization_endpoint_params.audience = some-audience-id
+management.oauth_authorization_endpoint_params.example = example-value
+
+management.oauth_token_endpoint_params.audience = some-audience-id
+management.oauth_token_endpoint_params.other = other-value
+```
+
+
 ### Special attention to CSP header `connect-src` {#csp-header}
 
 To support the OAuth 2.0 protocol, RabbitMQ makes asynchronous REST calls to the [OpenId Connect Discovery endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). If you override the default [CSP headers](#csp), you have to make sure that the `connect-src` CSP directive whitelists the [OpenId Connect Discovery endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest).
@@ -600,6 +629,18 @@ the following settings:
 - `resource` : `rabbit_prod`
 - `scopes` : `openid rabbitmq.tag:management rabbitmq.read:*/*`
 
+### Configure Extra URI Parameters for Authorization and Token Endpoints {#extra-endpoint-params}
+
+Some OAuth 2.0 providers require additional URI parameters to be included into the request sent to the **authorization endpoint** and/or to the **token endpoint**.
+These parameters are vendor- or IDP installation-specific. The Management UI already sends all the parameters required by the OAuth 2.0 Authorization Code flow.
+
+The following example sets an extra URI parameter called `audience` for both endpoints for the resource `some-resource-id`:
+
+```ini
+management.oauth_resource_servers.2.id = some-resource-id
+management.oauth_resource_servers.2.oauth_authorization_endpoint_params.audience = some-resource-id
+management.oauth_resource_servers.2.oauth_token_endpoint_params.audience = some-resource-id
+```
 
 #### Optionally do not expose some resources in the management UI
 
diff --git a/docs/oauth2-examples-auth0.md b/docs/oauth2-examples-auth0.md
index d3ae7bae4c..f0269c9828 100644
--- a/docs/oauth2-examples-auth0.md
+++ b/docs/oauth2-examples-auth0.md
@@ -1,5 +1,5 @@
 ---
-title: Use https://auth0.com/ as Auth 2.0 server
+title: Use auth0.com as OAuth 2.0 Server
 displayed_sidebar: docsSidebar
 ---
 <!--
@@ -19,18 +19,18 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-# Use https://auth0.com/ as OAuth 2.0 server
+# Use [auth0.com](https://auth0.com) as OAuth 2.0 server
 
 This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Auth0 as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
 
-* Have an account in https://auth0.com/.
+* Have an [Auth0](https://auth0.com/) account
 * Docker
 * A local clone of a [GitHub repository](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial) that contains all the configuration files and scripts used on this example
 
@@ -38,7 +38,7 @@ and Auth0 as Authorization Server using the following flows:
 
 In Auth0, resources are mapped to Application APIs.
 
-1. Once you have logged onto your account in https://auth0.com/, go to **dashboard > Applications > APIs > Create an API**.
+1. After logging into the Auth0 account, go to **dashboard > Applications > APIs > Create an API**.
 2. Give it the name `rabbitmq`. The important thing here is the `identifier` which must have the name of the *resource_server_id* we configured in RabbitMQ. This `identifier` goes into the `audience` JWT field. In our case, it is called `rabbitmq`.
 3. Choose `RS256` as the signing algorithm.
 4. Enable **RBAC**.
@@ -69,10 +69,9 @@ of the end user.
 In the settings, choose:
 
 * Application type : `Single Page applications`
-* Token Endpoint Authentication Method:  `None`
-* Allowed Callback URLs: `http://localhost:15672/js/oidc-oauth/login-callback.html`
-* Allowed Web Origins: `http://localhost:15672`
-* Allowed Origins (CORS): `http://localhost:15672`
+* Allowed Callback URLs: `https://localhost:15671/js/oidc-oauth/login-callback.html`
+* Allowed Web Origins: `https://localhost:15671`
+* Allowed Origins (CORS): `https://localhost:15671`
 
 
 ## Create a User for Management UI Access
@@ -100,8 +99,26 @@ To configure RabbitMQ you need to gather the following information from Auth0:
 4. And take note of the *Domain* value
 5. Use the last values in *Client ID* and *Domain* fields in the RabbitMQ configuration file
 
-Edit the configuration file [conf/auth0/rabbitmq.conf](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/conf/auth0/rabbitmq.conf) and replace `{CLIENT_ID}` and `{DOMAIN}` with the
-values you gathered above.
+Copy [conf/auth0/rabbitmq.conf.tmpl](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/conf/auth0/rabbitmq.conf.tmpl) as `rabbitmq.conf`.
+It must be in same folder as `rabbitmq.conf.tmpl`.
+
+Edit `rabbitmq.conf` and proceed as follows:
+
+1. Replace `{Client ID}` with the values you gathered above.
+2. Same for `{Domain}`
+
+:::important
+
+Starting with RabbitMQ 4.1.x, you must configure RabbitMQ to include a URI parameter
+called `audience` whose value matches the value of `auth_oauth2.resource_server_id`.
+
+Earlier RabbitMQ versions always sent this URI parameter. If this additional URI parameter is not configured,
+Auth0 will consider the token invalid and RabbitMQ will display "No authorized" for error.
+
+These [two configuration lines](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/conf/auth0/rabbitmq.conf.tmpl#L8-L9)
+configure the `audience` parameter with the value `rabbitmq`.
+
+:::
 
 ## Start RabbitMQ
 
@@ -114,7 +131,7 @@ make start-rabbitmq
 
 ## Verify Management UI flows
 
-1. Go to management UI `http://localhost:15672`.
+1. Go to management UI `https://localhost:15671`.
 2. Click on the single button, authenticate with your secondary Auth0 user. You should be redirected back to the management UI.
 
 **Auth0** issues an access token like this one below. It has in the `scope` claim
diff --git a/docs/oauth2-examples-entra-id/index.md b/docs/oauth2-examples-entra-id/index.md
index f737efdb4b..8026c2fc51 100644
--- a/docs/oauth2-examples-entra-id/index.md
+++ b/docs/oauth2-examples-entra-id/index.md
@@ -24,7 +24,8 @@ limitations under the License.
 This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Microsoft Entra ID as Authorization Server using the following flows:
 
-* Access the management UI via a browser
+* Access the management UI via a browser using v2.0 api version
+
 
 ## Prerequisites to follow this guide
 
@@ -48,7 +49,7 @@ When using **Entra ID as OAuth 2.0 server**, your client app (in our case Rabbit
 4. In the **Register an application** pane, provide the following information:
 
     * **Name**: the name you would like to give to your application (ex: *rabbitmq-oauth2*)
-    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (you can choose other options if you want to enlarge the audience of your app)
+    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (this guide will focus on this option for simplicity)
     * On the **Select a platform** drop-down list, select **Single-page application (SPA)**
     * Configure the **Redirect URI** to: `https://localhost:15671/js/oidc-oauth/login-callback.html`
 
@@ -65,16 +66,8 @@ When using **Entra ID as OAuth 2.0 server**, your client app (in our case Rabbit
 
     Note the following values, as you will need it later to configure the `rabbitmq_auth_backend_oauth2` on RabbitMQ side:
 
-    * Directory (tenant ID)
-    * Application (client) ID
-
-6. Click on the **Endpoints** tab if it is visible.
-7. On the right pane that has just opened, copy the value of **OpenID Connect metadata document** (ex: `https://login.microsoftonline.com/{TENANT_ID}/v2.0/.well-known/openid-configuration`) and open it in your browser.
-
-    Note the value of the `jwks_uri` key (ex: `https://login.microsoftonline.com/{TENANT_ID}/discovery/v2.0/keys`), as you will also need it later to configure the `rabbitmq_auth_backend_oauth2` on RabbitMQ side.
-
-    ![Entra ID JWKS URI](./entra-id-jwks-uri.png)
-8. If the **Endpoints** tab is not visible,
+    * **Directory (tenant ID)**
+    * **Application (client) ID**
 
 
 ## Create OAuth 2.0 roles for your app
@@ -97,18 +90,12 @@ To learn more about roles in Entra ID, see [Entra ID documentation](https://docs
 
 2. Then, click on **Create App Role** to create an OAuth 2.0 role that will be used to give access to the RabbitMQ Management UI.
 
-:::info
-
-To learn more about how permissions are managed when RabbitMQ is used together with OAuth 2.0,
-see [this portion of the OAuth 2 tutorial](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial#about-permissions)
-
-:::
 
 3. On the right menu that has just opened, provide the requested information:
 
     * **Display Name**: the name you want to give to the role (ex: *Management UI Admin*)
     * **Allowed member types**: Both (Users/Groups + Applications)
-    * **Value**: `Application_ID.tag:administrator` (where *Application_ID* is the value of the *Application (client) ID* noted earlier in this tutorial)
+    * **Value**: `{Application_ID}.tag:administrator` (where *Application_ID* is the value of the *Application (client) ID* noted earlier in this tutorial)
     * **Description**: briefly describe what this role aims to (here just to give admin access to the RabbitMQ Management UI)
     * **Do you want to enable this app role**: `yes` (check the box)
 
@@ -122,7 +109,7 @@ see [this portion of the OAuth 2 tutorial](https://github.com/rabbitmq/rabbitmq-
 
     * **Display Name**: the name you want to give to the role (ex: *Configure All Vhosts*)
     * **Allowed member types**: Both (Users/Groups + Applications)
-    * **Value**: `Application_ID.configure:*/*` (where *Application_ID* is the value of the *Application (client) ID* noted earlier in this tutorial)
+    * **Value**: `{Application_ID}.configure:*/*` (where *Application_ID* is the value of the *Application (client) ID* noted earlier in this tutorial)
     * **Description**: briefly describe what this role aims to (here to give permissions to configure all resources on all the vhosts available on the RabbitMQ instance)
     * **Do you want to enable this app role**: `yes` (check the box)
 
@@ -159,38 +146,57 @@ Now that some roles have been created for your application, you still need to as
 
 9. Repeat the operations for all the roles you want to assign.
 
-## Configure Custom Signing Keys
+## Create a Scope for Management UI Access
 
-It is optional to create a signing key for your application. If you create one though, you must append an `appid` query parameter containing the *app ID* to the `jwks_uri`. Otherwise, the standard jwks_uri endpoint will not include the custom signing key and RabbitMQ will not find the signing key to validate the token's signature.
+There is one last configuration step required. Without this step, the `access_token` returned
+by **Entra ID** won't be useable with RabbitMQ. More specifically, RabbitMQ will not be able to validate its signature because the `access_token` is meant for Microsoft resources
 
-For example, given your application id, `{my-app-id}` and your tenant `{tenant}`, the OIDC discovery endpoint uri would be `https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid={my-app-id}`. The returned payload contains the `jwks_uri` attribute whose value is something like `https://login.microsoftonline.com/{tenant}/discovery/keys?appid=<my-app-idp>`. RabbitMQ should be configured with that `jwks_uri` value.
+Therefore, create a new scope associated with the application registered above to be used for RabbitMQ management UI.
+To do so:
 
+1. Go to **App registrations**
+2. Click on your application
+3. Go to **Manage** option on the left menu and choose the option **Expose an API**
+4. Click on **Add a scope**
+5. Enter a name, eg. `management-ui`. Enter the same name for **Admin consent display name** and a description and save it
+7. The scope is named `api://{Application (client) ID}/{scope_name}`
 
-## Configure RabbitMQ to Use Entra ID as OAuth 2.0 Authentication Backend
+This scope will be used further below in this guide.
 
-The configuration on Entra ID side is done. Next, configure RabbitMQ to use these resources.
 
-[rabbitmq.conf](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/entra/rabbitmq.conf) is a sample RabbitMQ configuration to **enable Entra ID as OAuth 2.0 authentication backend** for the RabbitMQ Management UI.
+## Configure Custom Signing Keys
 
-Update it with the following values:
+Creating a signing key for the application is optional. If a custom key is created, RabbitMQ must be configured accordingly.
+In the example below, replace `{Application(client) ID}` with the actual *Application(client) ID*.
 
-* **Tenant ID** associated to the app that you registered in Entra ID
-* **Application ID** associated to the app that you registered in Entra ID
-* Value of the **jwks_uri** key from `https://login.microsoftonline.com/{TENANT_ID}/v2.0/.well-known/openid-configuration`
+Without this bit of configuration, the standard `jwks_uri` endpoint will not include the custom signing key
+and therefore RabbitMQ will not find the necessary signing key to validate the token's signature.
 
 ```ini
-auth_backends.1 = rabbit_auth_backend_oauth2
-auth_backends.2 = rabbit_auth_backend_internal
+auth_oauth2.discovery_endpoint_params.appid = {Application(client) ID}
+```
+
+For more information, check out Microsoft Entra documentation about [configuring custom signing keys](https://learn.microsoft.com/en-us/entra/identity-platform/jwt-claims-customization#validate-token-signing-key).
+
+
+## Configure RabbitMQ to Use Entra ID as OAuth 2.0 Authentication Backend
 
-management.oauth_enabled = true
-management.oauth_client_id = {PUT YOUR AZURE AD APPLICATION ID}
-management.oauth_provider_url = https://login.microsoftonline.com/{YOUR_ENTRA_ID_TENANT_ID}
+The configuration on **Entra ID** side is done. Next, configure RabbitMQ to use these resources.
 
-auth_oauth2.resource_server_id = {PUT YOUR AZURE AD APPLICATION ID}
-auth_oauth2.additional_scopes_key = roles
-auth_oauth2.jwks_url = {PUT YOUR ENTRA ID JWKS URI VALUE}
+Clone [rabbitmq.conf.tmpl](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/entra/rabbitmq.conf.tmpl) from the tutorial repository
+to `rabbitmq.conf`. It must be in the same directory as `rabbitmq.conf.tmpl`.
+
+Edit the new `rabbitmq.conf` file and proceed as follows:
+
+1. Replace `{Directory (tenant) ID}` with the value gathered earlier as **Application (client) ID**
+2. Replace `{Application(client) ID}` with the value gathered as **Application (client) ID**
+3. If you decide to configure your application with custom signing(s), you need to uncomment the following configuration line. This is required otherwise the `jwks_uri` endpoint announced by the OpenID Discovery endpoint does not contain applications' custom signing keys.
+
+```ini
+#auth_oauth2.discovery_endpoint_params.appid = {Application(client) ID}
 ```
 
+
 ## Start RabbitMQ
 
 Run the following commands to run RabbitMQ docker image:
@@ -201,8 +207,7 @@ make start-rabbitmq
 ```
 
 This starts a Docker container named `rabbitmq`, with RabbitMQ Management UI/API with HTTPS enabled, and configured to use your Entra ID as OAuth 2.0 authentication backend,
-based on the information you provided in [rabbitmq.conf](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/conf/entra/rabbitmq.conf)
-in the previous steps of this tutorial.
+based on the values set in `rabbitmq.conf` in the previous steps of this tutorial.
 
 ## Automatic generation of a TLS Certificate and Key Pair
 
diff --git a/docs/oauth2-examples-keycloak.md b/docs/oauth2-examples-keycloak.md
index 12fd9982a8..b982b331d5 100644
--- a/docs/oauth2-examples-keycloak.md
+++ b/docs/oauth2-examples-keycloak.md
@@ -25,7 +25,7 @@ This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Keycloak as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
diff --git a/docs/oauth2-examples-multiresource.md b/docs/oauth2-examples-multiresource.md
index 567d6d51d1..85d28fba09 100644
--- a/docs/oauth2-examples-multiresource.md
+++ b/docs/oauth2-examples-multiresource.md
@@ -67,6 +67,7 @@ The RabbitMQ OAuth 2 plugin is configured like so:
     auth_oauth2.preferred_username_claims.1 = preferred_username
     auth_oauth2.preferred_username_claims.2 = user_name
     auth_oauth2.preferred_username_claims.3 = email
+    auth_oauth2.issuer = https://keycloak:8443/realms/test
     auth_oauth2.scope_prefix = rabbitmq.
     ```
     * With one oauth provider:
diff --git a/docs/oauth2-examples-okta.md b/docs/oauth2-examples-okta.md
index f319f2ab5a..cb3046054a 100644
--- a/docs/oauth2-examples-okta.md
+++ b/docs/oauth2-examples-okta.md
@@ -45,8 +45,8 @@ Once you have logged onto your account in [Okta](https://www.okta.com), follow b
 
 1. In the Admin Console, go to Applications.
 1. Click Create App Integration.
-1. To create an OIDC app integration, select OIDC - OpenID Connect as the Sign-in method.
-1. Choose the type of application to integrate with Okta. Select Web Application, Single-Page Application, or Native Application. In our use case it is Single-Page Application(SPA).
+1. To create an OIDC app integration, select **OIDC - OpenID Connect** as the Sign-in method.
+1. Choose the type of application to integrate with Okta. Select **Single-Page Application(SPA)**.
 1. Click Next.
 
 The App Integration Wizard for OIDC has three sections:
@@ -56,18 +56,30 @@ In General Settings, provide the following information:
   - **Name**: App integration name: Specify a name for your app integrationn (ex: *rabbitmq-oauth2*)
   - **Grant type**: Select **Authorization Code** and **Refresh Token**
   - **Redirect URI**:
-    * On the **Sign-in redirect URIs** type http://localhost:15672/js/oidc-oauth/login-callback.html
-    * Configure the **Sign-out redirect URIs** to https://localhost:15672
+    * On the **Sign-in redirect URIs** type https://localhost:15671/js/oidc-oauth/login-callback.html
+    * Configure the **Sign-out redirect URIs** to https://localhost:15671
 
 In Trusted Origins (for Web and Native app integrations), choose **keep the default values**.
 
 In Assignments, choose **Allow everyone in your organization to access**.
 
-Finally, click on **Save** and write down the following values, as you will need them later to configure RabbitMQ:
+:::warning
+
+Deactivate `Federation Broker Mode`. Our testing suggests that if the `Federation Broker Mode` was activated (this is what Okta recommends),
+it would not possible to assign this application to groups and users.
+
+:::
+
+Finally, prepare to copy and save a value that will be displayed on one of the following screens,
+then click on **Save**.
+
+:::important
+
+After clicking **Save**, take note of the following values, the will be necessary later to configure RabbitMQ:
 
   * **ClientID**
-  * **Okta domain name**
 
+:::
 
 ## Create Okta OAuth 2.0 Authorization Server, Scopes and Claims
 
@@ -79,6 +91,14 @@ Here are the steps to create scopes for `admin` and `dev` groups using the defau
 
 2. Click on the default authorization server that is provided.
 
+:::tip
+Take note of the following fields associated to the default authorization server,
+as you will need them later to configure RabbitMQ.
+
+  * **Issuer**.
+  * **Metadata URI**.
+:::
+
 3. Click on the **Scopes** tab and then click the **Add Scope** button.
 
 4. Enter `admin` as the name of the scope and a description if desired.
@@ -147,18 +167,66 @@ to `dev` and `admin` group and assign the `rabbitmq-oauth2` app to both groups.
 
 Once you've added the user to the appropriate groups and apps, they should have access to the app and any resources associated with those groups.
 
+## Create access policy and rule
+
+This step is necessary otherwise the tokens do not carry any of the scopes granted to the users.
+
+1. [Create an access policy](https://developer.okta.com/docs/guides/customize-authz-server/main/#create-access-policies)
+2. [Create a rule](https://developer.okta.com/docs/guides/customize-authz-server/main/#create-rules-for-each-access-policy) for the access policy
+
+## [Optional] Test the Tokens Issued by Okta
+
+This step is optional but highly recommended.
+
+1. Go to the **default Authorization Server**
+2. Click on **Token Preview** tab
+3. Fill in all the fields. For **grant type** choose `Authorization Code`
+4. Click on **Preview Token** button
+5. Check the claim `role` to see if it contains the roles assigned earlier in this guide
+
 
 ## Configure RabbitMQ to use Okta as OAuth 2.0 Authentication Backend
 
-The configuration on Okta side is done. You now have to configure RabbitMQ to use the resources you just created.
+The configuration on the Okta side is done. Next, configure RabbitMQ to use the resources created above.
+
+For that, you will need the following values from the previous steps:
+
+* **okta_client_app_ID**: the ID of the app registered in Okta to be used with RabbitMQ
+* **okta-Issuer**: the **default Authorization server**
+* **okta-Metadata-URI**: the **default Authorization server**
+
+Copy [rabbitmq.conf.tmpl](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/okta/rabbitmq.conf.tmpl) from the tutorial repository
+to `rabbitmq.conf`. It must be in the same directory as `rabbitmq.conf.tmpl`.
+
+There is a second configuration file, [advanced.config](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/okta/advanced.config),
+that will not need any modifications. This is the RabbitMQ [advanced configuration file](./configure/) where RabbitMQ scopes are mapped to the permissions previously configured in Okta.
+
+Edit `rabbitmq.conf` and proceed as follows:
 
-[rabbitmq.conf](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/okta/rabbitmq.conf) is a RabbitMQ configuration to **enable okta as OAuth 2.0 authentication backend** for the RabbitMQ OAuth2 and Management plugins. And [advanced.config](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/tree/main/conf/okta/advanced.config) is the RabbitMQ advanced configuration that maps RabbitMQ scopes to the permissions previously configured in Okta.
+1. Replace `{okta_client_app_ID}` with your **okta_client_app_ID**
+2. Replace `{okta-issuer}` with your **okta-Issuer**
+3. Ensure **okta-Metadata-URI** matches this value `{okta-issuer}/.well-known/oauth-authorization-server`
+or `{okta-issuer}/.well-known/openid-configuration`
+4. Else you need to determine the path that follows the uri in `{okta-issuer}` and update
+`auth_oauth2.discovery_endpoint_path` accordingly. For instance, if **okta-Metadata-URI** is `{okta-issuer}/some-other-endpoint`, you update `auth_oauth2.discovery_endpoint_path` with the value `some-other-endpoint`.
 
-Update it with the following values (you should have noted these in the previous steps):
 
-  - **okta-domain-name** associated to your okta domain name.
-  - **okta_client_app_ID** associated to the okta app that you registered in okta for rabbitMQ.
+### About the OpenId Discovery Endpoint
 
+RabbitMQ uses the standard OpenId discovery endpoint path `.well-known/openid-configuration`. Okta supports this path in addition to `.well-known/oauth-authorization-server`.
+The only difference observed between the two endpoints is that the latter returns more values in the `claims_supported` JSON field.
+
+The RabbitMQ's template configuration provided in the snippet below has this line.
+This means that RabbitMQ will use the standard path.
+
+If the default does not work as expected, try uncommenting this line to use
+the alternative path.
+
+``` ini
+## Uncomment to use '.well-known/oauth-authorization-server' as the discovery
+## endpoint path
+# auth_oauth2.discovery_endpoint_path = .well-known/oauth-authorization-server
+```
 
 ## Start RabbitMQ
 
@@ -169,11 +237,9 @@ export MODE=okta
 make start-rabbitmq
 ```
 
-
 ## Verify RabbitMQ Management UI Access
 
-Go to RabbitMQ Management UI `https://localhost:15671`. Depending on your browser, ignore the security warnings (raised by the fact that a [self-signed certificate](./ssl#peer-verification) is used)
-to proceed.
+Go to RabbitMQ Management UI `https://localhost:15671`. Depending on your browser, ignore the security warnings (raised by the fact that a [self-signed certificate](./ssl#peer-verification) is used) to proceed.
 
 Once on the RabbitMQ Management UI page, click on the **Click here to log in** button,
 authenticate with your **okta user**.
diff --git a/docs/oauth2-examples/index.md b/docs/oauth2-examples/index.md
index 9cab50979d..980dc7e071 100644
--- a/docs/oauth2-examples/index.md
+++ b/docs/oauth2-examples/index.md
@@ -44,9 +44,9 @@ which hosts all the scripts required to deploy the examples demonstrated on the
 * [Service-Provider initiated logon](#service-provider-initiated-logon)
 * [Identity-Provider initiated logon](#identity-provider-initiated-logon)
 
-### Using [various protocols using JWT tokens](#access-other-protocols)
+### Using [JWT tokens in several protocols](#access-other-protocols) to access RabbitMQ
 
-* [Management UI](#management-ui)
+* [Management HTTP API](#management-http-api)
 * [AMQP 0-9-1](#amqp-protocol) (and [scopes for topic exchanges](#using-topic-exchanges) in a separate section)
 * [AMQP 1.0](#amqp10-protocol)
 * [JMS](#jms-clients)
@@ -142,7 +142,7 @@ in `rabbitmq.conf`:
 # ...
 management.oauth_enabled = true
 management.oauth_client_id = rabbit_client_code
-management.oauth_provider_url = http://localhost:8080
+auth_oauth2.issuer = http://localhost:8080
 # ...
 ```
 
@@ -178,21 +178,21 @@ in `rabbitmq.conf`:
 # ...
 management.oauth_enabled = true
 management.oauth_client_id = rabbit_client_code
-management.oauth_provider_url = http://localhost:8080
 management.oauth_initiated_logon_type = idp_initiated
+auth_oauth2.issuer = http://localhost:8080
 # ...
 ```
 
-**Important**: when the user logs out, or its RabbitMQ session expired, or the token expired, the user is directed to the
+**Important**: when the user logs out, or its RabbitMQ session expires, or the token expires, the user is directed to the
 RabbitMQ Management landing page which has a **Click here to login** button.
-The user is never automatically redirected back to the url configured in the `oauth_provider_url`.
-It is only when the user clicks **Click here to login** , the user is redirected to the configured url in `oauth_provider_url`.
+The user is never automatically redirected back to the url configured in the `auth_oauth2.issuer`.
+It is only when the user clicks **Click here to login** , the user is redirected to the configured url in `auth_oauth2.issuer`.
 
-## Access other protocols using OAuth 2.0 tokens {#access-other-protocols}
+## Using JWT tokens in several protocols to access RabbitMQ {#access-other-protocols}
 
-The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management rest api.
+The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management HTTP API.
 
-### Management REST api {#management-ui}
+### Management HTTP API {#management-http-api}
 
 In this scenario a monitoring agent uses RabbitMQ HTTP API to collect monitoring information.
 Because it is not an end user, or human, you refer to it as a *service account*.
@@ -509,7 +509,7 @@ This scenario explores the use case where JWT tokens may be signed by different
 
 There are two ways to configure RabbitMQ with multiple signing keys:
 
- * **Statically** configure them via `rabbitmq.conf` as shown in the [plugin documentation page](https://github.com/rabbitmq/rabbitmq-server/tree/main/deps/rabbitmq_auth_backend_oauth2#variables-configurable-in-rabbitmqconf).
+ * **Statically** configure them via `rabbitmq.conf` as shown in the [plugin documentation page](./oauth2#configure-signing-keys).
  * **Dynamically** add the keys to a running RabbitMQ node without having to restart it.
 
 First you add a second signing key called `legacy-token-2-key` whose public key is `conf/public-2.pem`:
@@ -530,17 +530,11 @@ make curl-with-token URL=http://localhost:15672/api/overview TOKEN=$(bin/jwt_tok
 
 ### Using Scope Aliases {#using-scope-aliases}
 
-In this use case you are going to demonstrate how to configure RabbitMQ to handle
-*custom scopes*. But what are *custom scopes*? They are any
-scope whose format is not compliant with RabbitMQ format. For instance, `api://rabbitmq:Read.All`
-is one of the custom scopes you will use in this use case.
+*Custom scopes*? are any scope whose format is not compliant with RabbitMQ format.
+For instance, `api://rabbitmq:Read.All` is one of the custom scopes you will use in this use case.
 
 #### How to Configure RabbitMQ to Use a Custom Scope Mapping
 
-Starting with [RabbitMQ `3.10.0`](https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.10.0),
-the OAuth 2.0 plugin supports mapping of a scope aliases (arbitrary scope values or "names") to one or more scopes
-in the format that follows the RabbitMQ OAuth 2.0 plugin conventions.
-
 See below a sample RabbitMQ configuration where you map `api://rabbitmq:Read.All`
 custom scope to `rabbitmq.read:*/*` RabbitMQ scope.
 
@@ -792,9 +786,9 @@ make start-rabbitmq
 **NOTE**: You do not need to run any OAuth 2.0 server like UAA. This is because you are creating a token and signing it using the same
 private-public key pair RabbitMQ is configured with.
 
-*Use a Rich Authorization Token to access the management rest api*
+*Use a Rich Authorization Token to access the management HTTP API*
 
-You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the management rest api.
+You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the Management HTTP API.
 
 ```bash
 make curl-with-token URL=http://localhost:15672/api/overview TOKEN=$(bin/jwt_token rar-token.json legacy-token-key private.pem public.pem)
diff --git a/docs/oauth2.md b/docs/oauth2.md
index 928eabab89..24f4c540ff 100644
--- a/docs/oauth2.md
+++ b/docs/oauth2.md
@@ -45,6 +45,7 @@ There's also a companion [troubleshooting guide for OAuth 2-specific problems](.
 * [Configure signing keys](#configure-signing-keys)
 * [Use a different token field for the scope](#use-different-token-field)
 * [Preferred username claims](#preferred-username-claims)
+* [Discovery Endpoint params](#discovery-endpoint-params)
 * [Rich Authorization Request](#rich-authorization-request)
 
 ### [Advanced usage](#advanced-usage)
@@ -102,11 +103,19 @@ Based on the previous configuration, JWT Tokens presented to RabbitMQ for authen
 2. have a value in the `aud` field that matches `resource_server_id` value
 3. have scopes that must match the `resource_server_id` value, for example `new_resource_server_id.read:*/*`
 
-Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS url to download the signing keys.
+Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS URL to download the signing keys.
 :::info
 *.well-known/openid-configuration* is the OpenID standard path for the OpenID Provider Configuration endpoint
 :::
 
+If the Identity Provider used exposes a different path and/or requires adding some extra URI parameters for the OpenID discovery endpoint,
+they can be configured as follows:
+
+```ini
+auth_oauth2.discovery_endpoint_path = my/custom/path
+auth_oauth2.discovery_endpoint_params.appid = some-app-id
+```
+
 More detail is included in the next section about what happens during the authentication and how to configure OAuth 2.0 beyond the basic configuration shown previously.
 
 ### Authorization Flow {#authorization-flow}
@@ -115,10 +124,10 @@ This plugin does not communicate with any OAuth 2.0 provider in order to authent
 
 Tokens must be digitally signed otherwise they are not accepted. RabbitMQ must have the signing key to validate the signature. You can either configure the signing keys the OAuth 2.0 provider will use, or configure RabbitMQ with one of the following two endpoints:
 
-  - **JWKS endpoint** - this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens.
-  - **OpenID Provider Configuration endpoint** - this is the endpoint that returns the provider's configuration including all its endpoints, such as the **JWKS endpoint**.
+* **JWKS endpoint**: this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens
+* **OpenID Provider Configuration endpoint**: this endpoint returns the provider's configuration including all of its endpoints, most importantly the **JWKS endpoint**
 
-When you configure RabbitMQ with one of two previous endpoints, RabbitMQ must make a HTTP request (or two, if we specify the latter endpoint) to download the signing keys. This is an operation that occurs once for any signing key not downloaded yet. When the OAuth 2.0 provider rotates the signing keys, newer tokens refer to a new signing key which RabbitMQ does not have yet which triggers another download of the newer signing keys.
+When RabbitMQ is configured with one of two previous endpoints, RabbitMQ must make a HTTP request (or two, if you specify the latter endpoint) to download the signing keys. This is an operation that occurs once for any signing key not downloaded yet. When the OAuth 2.0 provider rotates the signing keys, newer tokens refer to a new signing key which RabbitMQ does not have yet which triggers another download of the newer signing keys.
 
 The token can be any [JWT token](https://jwt.io/introduction/) which contains the `scope` and `aud` fields.
 
@@ -137,25 +146,27 @@ In chronological order, here is the sequence of events that occur when a client
 |--------------------------------------------|-----------
 | `auth_oauth2.resource_server_id`           | The [Resource Server ID](#resource-server-id)
 | `auth_oauth2.resource_server_type`         | The Resource Server Type required when using [Rich Authorization Request](#rich-authorization-request) token format
-| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format). |
-| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character. |
-| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token.
-| `auth_oauth2.default_key`                  | ID of the default signing key.
-| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files).
-| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server that is used to discover endpoints such as `jwk_uri` and others (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
-| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https.
-| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint.
-| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the `issuer`.
-| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
+| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format) |
+| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character |
+| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token
+| `auth_oauth2.default_key`                  | ID of the default signing key
+| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files)
+| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server. Used to build the discovery endpoint URL to discover other endpoints such as such as `jwks_uri`. Management UI users will be sent to this for logging in
+| `auth_oauth2.discovery_endpoint_path`      | The path used for the [OpenId discovery endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). The endpoint URI is built using `auth_oauth2.issuer`, this path or else the default path `.well-known/openid-configuration` followed by query parameters configured in the following variable
+| `auth_oauth2.discovery_endpoint_params`    | [List of HTTP query parameters](#discovery-endpoint-params) sent to the OpenId discovery endpoint
+| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema. Optional if you set `auth_oauth2.issuer`. If this URL is set, it overrides the `jwks_uri` discovered via the discovery endpoint
+| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint. Optional if you set `auth_oauth2.issuer`. If this URL is set, it overrides the `token_endpoint` discovered via the discovery endpoint
+| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the discovery endpoint
+| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10
 | `auth_oauth2.https.peer_verification`      | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable.
-| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`.
-| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`.
-| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false.
-| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support).
-| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`.
-| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration).
-| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration).
-| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing.
+| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`
+| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`
+| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false
+| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support)
+| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`
+| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration)
+| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration)
+| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing
 
 
 #### Resource Server ID {#resource-server-id}
@@ -206,7 +217,7 @@ auth_oauth2.algorithms.2 = RS256
 
 #### JWKS endpoint {#jwks-endpoint}
 
-The followibng configuration sets the JWKS endpoint from which RabbitMQ downloads the signing keys using the configured CA certificate and TLS variables.
+The following configuration sets the JWKS endpoint from which RabbitMQ downloads the signing keys using the configured CA certificate and TLS variables.
 
 ```ini
 auth_oauth2.resource_server_id = new_resource_server_id
@@ -220,13 +231,14 @@ auth_oauth2.algorithms.1 = HS256
 auth_oauth2.algorithms.2 = RS256
 ```
 
+
 #### Multiple Resource Servers configuration {#multiple-resource-servers-configuration}
 
 Each `auth_oauth2.resource_servers.<id/index>.` entry has the following variables shown in the table below. Except for the variables `id` and `oauth_provider_id`, if a resource does not configure a variable, RabbitMQ uses the variable configured at the root level. For instance, if the resource `auth_oauth2.resource_servers.prod` does not configure `preferred_username_claims` variable, RabbitMQ uses the value configured in `auth_oauth2.preferred_username_claims` for the resource `prod`.
 
 | Key                          | Documentation
 |------------------------------|-----------
-| `id`                         | The [Resource Server ID](#resource-server-id)
+| `id`                         | The [Resource Server ID](#resource-server-id).
 | `resource_server_type`       | The Resource Server Type required when using [Rich Authorization Request](#rich-authorization-request) token format.
 | `additional_scopes_key`      | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format).
 | `scope_prefix`               | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character.
@@ -254,18 +266,20 @@ Each `auth_oauth2.oauth_providers.{id/index}` entry has the following sub-keys.
 
 | Key                          | Documentation
 |------------------------------|-----------
-| `issuer`                     | URL of OAuth Provider. RabbitMQ uses this URL to build the OpenId Connect Discovery endpoint by appending the path `.well-known/openid-configuration` to this URL
-| `token_endpoint`             | The URL of the OAuth 2.0 token endpoint.
-| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`.
-| `https.cacertfile`           | Path to a file containing PEM-encoded CA certificates used to connect `issuer` and/or `jwks_uri` URLs
+| `issuer`                     | URL of OAuth Provider. It is used to build the discovery endpoint URL and/or to redirect RabbitMQ Management users to login and get a token.
+| `discovery_endpoint_path`    | The path used for the OpenId discovery endpoint. Default value is `.well-known/openid-configuration`
+| `discovery_endpoint_params`  | [List of HTTP query parameters](#discovery-endpoint-params) sent to the OpenId discovery endpoint.
+| `token_endpoint`             | The URL of the OAuth 2.0 token endpoint. Optional if you configured `issuer`.
+| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`. This variable is optional if you set `issuer`.
+| `https.cacertfile`           | Path to a file containing PEM-encoded CA certificates used to connect `issuer` and/or `jwks_uri` URLs.
 | `https.depth`                | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
 | `https.verify`               | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set.
 | `https.fail_if_no_peer_cert` | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`.
 | `https.hostname_verification` | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`.
 | `https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false.
-| `signing_keys`               | Local filesystem paths to the [signing key files](#signing-key-files). The files must exist and be readable
-| `default_key`                | ID of the default signing key
-| `algorithms`                 | Used to restrict [the list of enabled algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support)
+| `signing_keys`               | Local filesystem paths to the [signing key files](#signing-key-files). The files must exist and be readable.
+| `default_key`                | ID of the default signing key.
+| `algorithms`                 | Used to restrict [the list of enabled algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support).
 
 Here is an example which configures two resources (`prod` and `dev`) where each resource is managed by two distinct identity providers:
 
@@ -300,8 +314,7 @@ It contains the expiration time after which the JWT MUST NOT be accepted for pro
 The `aud` ([Audience](https://tools.ietf.org/html/rfc7519#page-9)) identifies the recipients and/or resource_server of the JWT.
 
 By default, **RabbitMQ uses this field to validate the token**. This validation can be disabled by setting the `auth_oauth2.verify_aud` setting set to `false`.
-When verification is enabled, this `aud` field must either match the `resource_server_id` value or, in case of a list,
-it must contain the `resource_server_id` value.
+When verification is enabled, this `aud` field must either match the `resource_server_id` value or, in case of a list, it must contain the `resource_server_id` value.
 
 ### Token expiration and refresh {#token-expiration}
 
@@ -403,7 +416,7 @@ the `monitoring` tag will be `my_rabbit.tag:monitoring`.
 
 Before RabbitMQ 3.13, users had to either configure the JWKS endpoint (that is `auth_oauth2.jwks_url` variable) or statically [configure the signing keys](#configure-signing-keys). Now, users only need to configure the OpenID Provider's **issuer** URL and from this URL RabbitMQ downloads the OpenID Provider configuration which includes the JWKS endpoint in addition to other endpoints which will be useful in other contexts.
 
-Usually, this **issuer** URL is the same URL configured in the management plugin (`management.oauth_provider_url`). From now on, you only need to configure a single URL, specified by the `auth_oauth2.issuer` variable. Except in edge cases where the **issuer** URL does not host the login page. In that cases, the user configures the login page in the `management.oauth_provider_url` variable.
+Usually, this **issuer** URL is the same URL configured in the management plugin (`management.oauth_provider_url`). From now on, you only need to configure a single URL, specified by the `auth_oauth2.issuer` variable. Except in edge cases where the **issuer** URL does not host the login page. In those cases, the user configures the login page in the `management.oauth_provider_url` variable.
 
 Sample configuration using issuer:
 ```ini
@@ -417,13 +430,12 @@ auth_oauth2.resource_server_id = my_rabbit_server
 auth_oauth2.jwks_url = "https://my-jwt-issuer/jwks.json
 ```
 
-
 :::info
 If you have both endpoints configured, RabbitMQ uses `jwks_url` because it does not need to discover it via the `issuer` url.
 :::
 
 :::info
-**Note about TLS variables for the `jwks_url` or the `issuer` url**: TLS variable such as the `cacertfile` are configured as follows regardless which url we are using:
+**Note about TLS variables for the `jwks_url` or the `issuer` url**: TLS variable such as the `cacertfile` are configured as follows regardless which url you are using:
 :::
 
 ```ini
@@ -432,7 +444,6 @@ auth_oauth2.https.cacertfile = /opts/certs/cacert.pem
 ...
 ```
 
-
 **VERY IMPORTANT**: Since RabbitMQ 3.13, if `auth_oauth2.https.peer_verification` variable is not set, RabbitMQ sets it to `verify_peer` as long as there are trusted certificates installed in the OS or the user configured `auth_oauth2.https.cacertfile`.
 
 ### Configure signing keys {#configure-signing-keys}
@@ -534,6 +545,28 @@ auth_oauth2.preferred_username_claims.2 = email
 
 In the example configuration, RabbitMQ searches for the `user_name` claim first and if it is not found, RabbitMQ searches for the `email`. If these are not found, RabbitMQ uses its default lookup mechanism which first looks for `sub` and then `client_id`.
 
+
+### Discovery endpoint parameters {#discovery-endpoint-params}
+
+Some OAuth 2.0 providers requires certain query parameters in the OpenId Discovery endpoint. For instance, Microsoft Entra ID requires a query parameter called `appid` when the application uses custom signing keys. The discovery endpoint returns an OpenId configuration tailored for the application that matches the `appid`.
+For instance, the `jkws_uri` endpoint returned in the OpenId configuration has already the query parameters sent to the discovery endpoint.
+
+Here is an example of setting these parameters including the rest of the variables used to build the OpenId discovery endpoint URL.
+
+``` ini
+# ...
+auth_oauth2.issuer = https://myissuer.com/v2
+auth_oauth2.discovery_endpoint_path = .well-known/authorization-server
+auth_oauth2.discovery_endpoint_params.param1 = value1
+auth_oauth2.discovery_endpoint_params.param2 = value2
+# ...
+```
+
+This is the URL built to access the OpenId Discovery endpoint:
+```
+https://myissuer.com/v2/.well-known/authorization-server?param1=value1&param2=value2
+```
+
 ### Rich Authorization Request {#rich-authorization-request}
 
 The [Rich Authorization Request](https://oauth.net/2/rich-authorization-requests/) extension provides a way for
@@ -729,8 +762,6 @@ auth_oauth2.oauth_providers.prodkeycloak.issuer = https://prodkeycloak:8080/real
 auth_oauth2.oauth_providers.prodkeycloak.end_session_endpoint = https://prodkeycloak:8080/realm/prod/logout
 ```
 
-
-
 ### Configure multiple resource servers {#multiple-resource-servers}
 
 Usually, all users that access a RabbitMQ cluster are registered within the same identity provider. Likewise, all tokens targeting the same RabbitMQ cluster also carry the same *audience*. In other words, all users reference a RabbitMQ cluster with the same resource name which must match the value of the `auth_oauth2.resource_server_id` variable.
diff --git a/package-lock.json b/package-lock.json
index c5242890c3..c354db149c 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -162,9 +162,9 @@
       }
     },
     "node_modules/@algolia/client-common": {
-      "version": "5.7.0",
-      "resolved": "https://registry.npmjs.org/@algolia/client-common/-/client-common-5.7.0.tgz",
-      "integrity": "sha512-hrYlN9yNQukmNj8bBlw9PCXi9jmRQqNUXaG6MXH1aDabjO6YD1WPVqTvaELbIBgTbDJzCn0R2owms0uaxQkjUg==",
+      "version": "5.8.0",
+      "resolved": "https://registry.npmjs.org/@algolia/client-common/-/client-common-5.8.0.tgz",
+      "integrity": "sha512-KSnRo4q8Ne9McDKxb1i4mDFNiRt8vT9SzJDitax/2qYYWyhPP0pvQ6jl7f00zovfsBg8lVabDdDAhDgY5PIvvA==",
       "license": "MIT",
       "peer": true,
       "engines": {
@@ -193,16 +193,16 @@
       }
     },
     "node_modules/@algolia/client-search": {
-      "version": "5.7.0",
-      "resolved": "https://registry.npmjs.org/@algolia/client-search/-/client-search-5.7.0.tgz",
-      "integrity": "sha512-0Frfjt4oxvVP2qsTQAjwdaG5SvJ3TbHBkBrS6M7cG5RDrgHqOrhBnBGCFT+YO3CeNK54r+d57oB1VcD2F1lHuQ==",
+      "version": "5.8.0",
+      "resolved": "https://registry.npmjs.org/@algolia/client-search/-/client-search-5.8.0.tgz",
+      "integrity": "sha512-meIT0dIjafbDhZGfXMZ02pKbvNjItH8yZORTLpA2wYWBpRWqGzNDXedD/ayFh/tm5+L0IGlSWIgfhofKfDRsFQ==",
       "license": "MIT",
       "peer": true,
       "dependencies": {
-        "@algolia/client-common": "5.7.0",
-        "@algolia/requester-browser-xhr": "5.7.0",
-        "@algolia/requester-fetch": "5.7.0",
-        "@algolia/requester-node-http": "5.7.0"
+        "@algolia/client-common": "5.8.0",
+        "@algolia/requester-browser-xhr": "5.8.0",
+        "@algolia/requester-fetch": "5.8.0",
+        "@algolia/requester-node-http": "5.8.0"
       },
       "engines": {
         "node": ">= 14.0.0"
@@ -288,13 +288,13 @@
       }
     },
     "node_modules/@algolia/requester-browser-xhr": {
-      "version": "5.7.0",
-      "resolved": "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-5.7.0.tgz",
-      "integrity": "sha512-ohtIp+lyTGM3agrHyedC3w7ijfdUvSN6wmGuKqUezrNzd0nCkFoLW0OINlyv1ODrTEVnL8PAM/Zqubjafxd/Ww==",
+      "version": "5.8.0",
+      "resolved": "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-5.8.0.tgz",
+      "integrity": "sha512-Gi33fRclktW+zJSmT2Gkntiu+BNkh+50NhfYLALHV4yZ3jH73PYbPNURFa1/NxaUpzPvXrld0BrsHDTS1QBBTQ==",
       "license": "MIT",
       "peer": true,
       "dependencies": {
-        "@algolia/client-common": "5.7.0"
+        "@algolia/client-common": "5.8.0"
       },
       "engines": {
         "node": ">= 14.0.0"
@@ -307,26 +307,26 @@
       "license": "MIT"
     },
     "node_modules/@algolia/requester-fetch": {
-      "version": "5.7.0",
-      "resolved": "https://registry.npmjs.org/@algolia/requester-fetch/-/requester-fetch-5.7.0.tgz",
-      "integrity": "sha512-Eg8cBhNg2QNnDDldyK77aXvg3wIc5qnpCDCAJXQ2oaqZwwvvYaTgnP1ofznNG6+klri4Fk1YAaC9wyDBhByWIA==",
+      "version": "5.8.0",
+      "resolved": "https://registry.npmjs.org/@algolia/requester-fetch/-/requester-fetch-5.8.0.tgz",
+      "integrity": "sha512-ve7ynA+O0KDrA2AAQ62GKQB+HjdHd0gX3tsXwlcfFOd7CYb2+xc+eOrVXV9mSlGS6Ssrd8V0AQ6BMId5KyypwQ==",
       "license": "MIT",
       "peer": true,
       "dependencies": {
-        "@algolia/client-common": "5.7.0"
+        "@algolia/client-common": "5.8.0"
       },
       "engines": {
         "node": ">= 14.0.0"
       }
     },
     "node_modules/@algolia/requester-node-http": {
-      "version": "5.7.0",
-      "resolved": "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-5.7.0.tgz",
-      "integrity": "sha512-8BDssYEkcp1co06KtHO9b37H+5zVM/h+5kyesJb2C2EHFO3kgzLHWl/JyXOVtYlKQBkmdObYOI0s6JaXRy2yQA==",
+      "version": "5.8.0",
+      "resolved": "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-5.8.0.tgz",
+      "integrity": "sha512-2sv9af4Pg58soGj3F0czK8xT2RVh/cX7UmMMjTQwkp7LK7SMW9OoDmg9FSvU5ge6KH0wd1TrxT/4XgRHc1P/NA==",
       "license": "MIT",
       "peer": true,
       "dependencies": {
-        "@algolia/client-common": "5.7.0"
+        "@algolia/client-common": "5.8.0"
       },
       "engines": {
         "node": ">= 14.0.0"
@@ -3826,9 +3826,9 @@
       "license": "MIT"
     },
     "node_modules/@types/node": {
-      "version": "22.7.4",
-      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.7.4.tgz",
-      "integrity": "sha512-y+NPi1rFzDs1NdQHHToqeiX2TIS79SWEAw9GYhkkx8bD0ChpfqC+n2j5OXOCpzfojBEBt6DnEnnG9MY0zk1XLg==",
+      "version": "22.7.5",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.7.5.tgz",
+      "integrity": "sha512-jML7s2NAzMWc//QSJ1a3prpk78cOPchGvXJsC3C6R6PSMoooztvRVQEz89gmBTBY1SPMaqo5teB4uNHPdetShQ==",
       "license": "MIT",
       "dependencies": {
         "undici-types": "~6.19.2"
@@ -5403,9 +5403,9 @@
       "license": "MIT"
     },
     "node_modules/cookie": {
-      "version": "0.6.0",
-      "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.6.0.tgz",
-      "integrity": "sha512-U71cyTamuh1CRNCfpGY6to28lxvNwPG4Guz/EVjgf3Jmzv0vlDp1atT9eS5dDjMYHucpHbWns6Lwf3BKz6svdw==",
+      "version": "0.7.1",
+      "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.7.1.tgz",
+      "integrity": "sha512-6DnInpx7SJ2AK3+CTUE/ZM0vWTUboZCegxhC2xiIydHR9jNuTAASBrfEpHhiGOZw/nX51bHt6YQl8jsGo4y/0w==",
       "license": "MIT",
       "engines": {
         "node": ">= 0.6"
@@ -6808,9 +6808,9 @@
       "license": "MIT"
     },
     "node_modules/electron-to-chromium": {
-      "version": "1.5.32",
-      "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.5.32.tgz",
-      "integrity": "sha512-M+7ph0VGBQqqpTT2YrabjNKSQ2fEl9PVx6AK3N558gDH9NO8O6XN9SXXFWRo9u9PbEg/bWq+tjXQr+eXmxubCw==",
+      "version": "1.5.33",
+      "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.5.33.tgz",
+      "integrity": "sha512-+cYTcFB1QqD4j4LegwLfpCNxifb6dDFUAwk6RsLusCwIaZI6or2f+q8rs5tTB2YC53HhOlIbEaqHMAAC8IOIwA==",
       "license": "ISC"
     },
     "node_modules/elkjs": {
@@ -7185,9 +7185,9 @@
       }
     },
     "node_modules/express": {
-      "version": "4.21.0",
-      "resolved": "https://registry.npmjs.org/express/-/express-4.21.0.tgz",
-      "integrity": "sha512-VqcNGcj/Id5ZT1LZ/cfihi3ttTn+NJmkli2eZADigjq29qTlWi/hAQ43t/VLPq8+UX06FCEx3ByOYet6ZFblng==",
+      "version": "4.21.1",
+      "resolved": "https://registry.npmjs.org/express/-/express-4.21.1.tgz",
+      "integrity": "sha512-YSFlK1Ee0/GC8QaO91tHcDxJiE/X4FbpAyQWkxAvG6AXCuR65YzK8ua6D9hvi/TzUfZMpc+BwuM1IPw8fmQBiQ==",
       "license": "MIT",
       "dependencies": {
         "accepts": "~1.3.8",
@@ -7195,7 +7195,7 @@
         "body-parser": "1.20.3",
         "content-disposition": "0.5.4",
         "content-type": "~1.0.4",
-        "cookie": "0.6.0",
+        "cookie": "0.7.1",
         "cookie-signature": "1.0.6",
         "debug": "2.6.9",
         "depd": "2.0.0",
@@ -8603,9 +8603,9 @@
       }
     },
     "node_modules/http-proxy-middleware": {
-      "version": "2.0.6",
-      "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-2.0.6.tgz",
-      "integrity": "sha512-ya/UeJ6HVBYxrgYotAZo1KvPWlgB48kUJLDePFeneHsVujFaW5WNj2NgWCAE//B1Dl02BIfYlpNgBy8Kf8Rjmw==",
+      "version": "2.0.7",
+      "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-2.0.7.tgz",
+      "integrity": "sha512-fgVY8AV7qU7z/MmXJ/rxwbrtQH4jBQ9m7kp3llF0liB7glmFeVZFBepQb32T3y8n8k2+AEYuMPCpinYW+/CuRA==",
       "license": "MIT",
       "dependencies": {
         "@types/http-proxy": "^1.17.8",
@@ -14380,9 +14380,9 @@
       "license": "MIT"
     },
     "node_modules/regjsparser": {
-      "version": "0.11.0",
-      "resolved": "https://registry.npmjs.org/regjsparser/-/regjsparser-0.11.0.tgz",
-      "integrity": "sha512-vTbzVAjQDzwQdKuvj7qEq6OlAprCjE656khuGQ4QaBLg7abQ9I9ISpmLuc6inWe7zP75AECjqUa4g4sdQvOXhg==",
+      "version": "0.11.1",
+      "resolved": "https://registry.npmjs.org/regjsparser/-/regjsparser-0.11.1.tgz",
+      "integrity": "sha512-1DHODs4B8p/mQHU9kr+jv8+wIC9mtG4eBHxWxIq5mhjE3D5oORhCc6deRKzTjs9DcfRFmj9BHSDguZklqCGFWQ==",
       "license": "BSD-2-Clause",
       "dependencies": {
         "jsesc": "~3.0.2"
@@ -15976,9 +15976,9 @@
       }
     },
     "node_modules/typescript": {
-      "version": "5.6.2",
-      "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.6.2.tgz",
-      "integrity": "sha512-NW8ByodCSNCwZeghjN3o+JX5OFH0Ojg6sadjEKY4huZ52TqbJTJnDo5+Tw98lSy63NZvi4n+ez5m2u5d4PkZyw==",
+      "version": "5.6.3",
+      "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.6.3.tgz",
+      "integrity": "sha512-hjcS1mhfuyi4WW8IWtjP7brDrG2cuDZukyrYrSauoXGNgx0S7zceP07adYkJycEr56BOUTNPzbInooiN3fn1qw==",
       "license": "Apache-2.0",
       "peer": true,
       "bin": {
diff --git a/versioned_docs/version-3.13/management/index.md b/versioned_docs/version-3.13/management/index.md
index 9ac3ef844f..1e04df2070 100644
--- a/versioned_docs/version-3.13/management/index.md
+++ b/versioned_docs/version-3.13/management/index.md
@@ -406,7 +406,7 @@ Given above configuration, when a user visits the management UI, the following t
 1. RabbitMQ uses the URL found in `auth_oauth2.issuer` followed by the path `/.well-known/openid-configuration` to download the OpenID Provider configuration. It contains information about other endpoints such as the `jwks_uri` (used to download the keys to validate the token's signature) or the `token_endpoint`.
 
     :::warning
-    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and OAuth 2.0 authentication is disabled in the management UI.
+    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and the OAuth 2.0 authentication option will be disabled in the management UI
     :::
 
 2. RabbitMQ displays a button with the label "Click here to login". When the user clicks on the button, the management UI initiates the OAuth 2.0 Authorization Code Flow, which redirects the user to the identity provider to authenticate and get a token.
diff --git a/versioned_docs/version-3.13/oauth2-examples-auth0.md b/versioned_docs/version-3.13/oauth2-examples-auth0.md
index d3ae7bae4c..d1b7080357 100644
--- a/versioned_docs/version-3.13/oauth2-examples-auth0.md
+++ b/versioned_docs/version-3.13/oauth2-examples-auth0.md
@@ -1,5 +1,5 @@
 ---
-title: Use https://auth0.com/ as Auth 2.0 server
+title: Use auth0.com as OAuth 2.0 Server
 displayed_sidebar: docsSidebar
 ---
 <!--
@@ -19,18 +19,18 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-# Use https://auth0.com/ as OAuth 2.0 server
+# Use [auth0.com](https://auth0.com) as OAuth 2.0 server
 
 This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Auth0 as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
 
-* Have an account in https://auth0.com/.
+* Have an [Auth0](https://auth0.com/) account.
 * Docker
 * A local clone of a [GitHub repository](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial) that contains all the configuration files and scripts used on this example
 
@@ -38,7 +38,7 @@ and Auth0 as Authorization Server using the following flows:
 
 In Auth0, resources are mapped to Application APIs.
 
-1. Once you have logged onto your account in https://auth0.com/, go to **dashboard > Applications > APIs > Create an API**.
+1. After logging into the Auth0 account, go to **dashboard > Applications > APIs > Create an API**.
 2. Give it the name `rabbitmq`. The important thing here is the `identifier` which must have the name of the *resource_server_id* we configured in RabbitMQ. This `identifier` goes into the `audience` JWT field. In our case, it is called `rabbitmq`.
 3. Choose `RS256` as the signing algorithm.
 4. Enable **RBAC**.
diff --git a/versioned_docs/version-3.13/oauth2-examples-entra-id/index.md b/versioned_docs/version-3.13/oauth2-examples-entra-id/index.md
index f737efdb4b..9ffec54cc9 100644
--- a/versioned_docs/version-3.13/oauth2-examples-entra-id/index.md
+++ b/versioned_docs/version-3.13/oauth2-examples-entra-id/index.md
@@ -48,7 +48,7 @@ When using **Entra ID as OAuth 2.0 server**, your client app (in our case Rabbit
 4. In the **Register an application** pane, provide the following information:
 
     * **Name**: the name you would like to give to your application (ex: *rabbitmq-oauth2*)
-    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (you can choose other options if you want to enlarge the audience of your app)
+    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (this guide will focus on this option for simplicity)
     * On the **Select a platform** drop-down list, select **Single-page application (SPA)**
     * Configure the **Redirect URI** to: `https://localhost:15671/js/oidc-oauth/login-callback.html`
 
diff --git a/versioned_docs/version-3.13/oauth2-examples-keycloak.md b/versioned_docs/version-3.13/oauth2-examples-keycloak.md
index 12fd9982a8..b982b331d5 100644
--- a/versioned_docs/version-3.13/oauth2-examples-keycloak.md
+++ b/versioned_docs/version-3.13/oauth2-examples-keycloak.md
@@ -25,7 +25,7 @@ This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Keycloak as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
diff --git a/versioned_docs/version-3.13/oauth2-examples/index.md b/versioned_docs/version-3.13/oauth2-examples/index.md
index 919a7a626d..6af703ee37 100644
--- a/versioned_docs/version-3.13/oauth2-examples/index.md
+++ b/versioned_docs/version-3.13/oauth2-examples/index.md
@@ -190,9 +190,9 @@ It is only when the user clicks **Click here to login** , the user is redirected
 
 ## Access other protocols using OAuth 2.0 tokens {#access-other-protocols}
 
-The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management rest api.
+The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management HTTP API.
 
-### Management REST api {#management-ui}
+### Management HTTP API {#management-ui}
 
 In this scenario a monitoring agent uses RabbitMQ HTTP API to collect monitoring information.
 Because it is not an end user, or human, you refer to it as a *service account*.
@@ -792,9 +792,9 @@ make start-rabbitmq
 **NOTE**: You do not need to run any OAuth 2.0 server like UAA. This is because you are creating a token and signing it using the same
 private-public key pair RabbitMQ is configured with.
 
-*Use a Rich Authorization Token to access the management rest api*
+*Use a Rich Authorization Token to access the management HTTP API*
 
-You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the management rest api.
+You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the Management HTTP API.
 
 ```bash
 make curl-with-token URL=http://localhost:15672/api/overview TOKEN=$(bin/jwt_token rar-token.json legacy-token-key private.pem public.pem)
diff --git a/versioned_docs/version-3.13/oauth2.md b/versioned_docs/version-3.13/oauth2.md
index 85ae9bf1c8..71471f12d3 100644
--- a/versioned_docs/version-3.13/oauth2.md
+++ b/versioned_docs/version-3.13/oauth2.md
@@ -102,7 +102,7 @@ Based on the previous configuration, JWT Tokens presented to RabbitMQ for authen
 2. have a value in the `aud` field that matches `resource_server_id` value
 3. have scopes that must match the `resource_server_id` value, for example `new_resource_server_id.read:*/*`
 
-Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS url to download the signing keys.
+Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS URL to download the signing keys.
 :::info
 *.well-known/openid-configuration* is the OpenID standard path for the OpenID Provider Configuration endpoint
 :::
@@ -115,8 +115,8 @@ This plugin does not communicate with any OAuth 2.0 provider in order to authent
 
 Tokens must be digitally signed otherwise they are not accepted. RabbitMQ must have the signing key to validate the signature. You can either configure the signing keys the OAuth 2.0 provider will use, or configure RabbitMQ with one of the following two endpoints:
 
-  - **JWKS endpoint** - this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens.
-  - **OpenID Provider Configuration endpoint** - this is the endpoint that returns the provider's configuration including all its endpoints, such as the **JWKS endpoint**.
+* **JWKS endpoint**: this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens.
+* **OpenID Provider Configuration endpoint**: this endpoint returns the provider's configuration including all of its endpoints, most importantly the **JWKS endpoint**
 
 When you configure RabbitMQ with one of two previous endpoints, RabbitMQ must make a HTTP request (or two, if we specify the latter endpoint) to download the signing keys. This is an operation that occurs once for any signing key not downloaded yet. When the OAuth 2.0 provider rotates the signing keys, newer tokens refer to a new signing key which RabbitMQ does not have yet which triggers another download of the newer signing keys.
 
@@ -137,25 +137,25 @@ In chronological order, here is the sequence of events that occur when a client
 |--------------------------------------------|-----------
 | `auth_oauth2.resource_server_id`           | The [Resource Server ID](#resource-server-id)
 | `auth_oauth2.resource_server_type`         | The Resource Server Type required when using [Rich Authorization Request](#rich-authorization-request) token format
-| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format). |
-| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character. |
-| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token.
-| `auth_oauth2.default_key`                  | ID of the default signing key.
-| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files).
-| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server that is used to discover endpoints such as `jwk_uri` and others (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
-| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https.
-| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint.
-| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the `issuer`.
-| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
-| `auth_oauth2.https.peer_verification`      | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable.
-| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`.
-| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`.
-| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false.
-| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support).
-| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`.
-| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration).
-| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration).
-| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing.
+| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format) |
+| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character |
+| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token
+| `auth_oauth2.default_key`                  | ID of the default signing key
+| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files)
+| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server. Used to build the discovery endpoint URL to discover other endpoints such as such as `jwks_uri`. Management UI users will be sent to this for logging in
+| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema
+| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint
+| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the `issuer`
+| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10
+| `auth_oauth2.https.peer_verification`      | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable
+| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`
+| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`
+| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false
+| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support)
+| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`
+| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration)
+| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration)
+| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing
 
 
 #### Resource Server ID {#resource-server-id}
@@ -247,7 +247,7 @@ Each `auth_oauth2.oauth_providers.<id/index>.` entry has the following variables
 |------------------------------|-----------
 | `issuer`                     | URL of OAuth Provider. RabbitMQ uses this URL to build the OpenId Connect Discovery endpoint by appending the path `.well-known/openid-configuration` to this URL
 | `token_endpoint`             | The URL of the OAuth 2.0 token endpoint.
-| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`.
+| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`.
 | `https.cacertfile`           | Path to a file containing PEM-encoded CA certificates used to connect `issuer` and/or `jwks_uri` URLs
 | `https.depth`                | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
 | `https.verify`               | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set.
diff --git a/versioned_docs/version-4.0/management/index.md b/versioned_docs/version-4.0/management/index.md
index 9ac3ef844f..1e04df2070 100644
--- a/versioned_docs/version-4.0/management/index.md
+++ b/versioned_docs/version-4.0/management/index.md
@@ -406,7 +406,7 @@ Given above configuration, when a user visits the management UI, the following t
 1. RabbitMQ uses the URL found in `auth_oauth2.issuer` followed by the path `/.well-known/openid-configuration` to download the OpenID Provider configuration. It contains information about other endpoints such as the `jwks_uri` (used to download the keys to validate the token's signature) or the `token_endpoint`.
 
     :::warning
-    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and OAuth 2.0 authentication is disabled in the management UI.
+    If RabbitMQ cannot download the OpenID provider configuration, it shows an error message and the OAuth 2.0 authentication option will be disabled in the management UI
     :::
 
 2. RabbitMQ displays a button with the label "Click here to login". When the user clicks on the button, the management UI initiates the OAuth 2.0 Authorization Code Flow, which redirects the user to the identity provider to authenticate and get a token.
diff --git a/versioned_docs/version-4.0/oauth2-examples-auth0.md b/versioned_docs/version-4.0/oauth2-examples-auth0.md
index d3ae7bae4c..d1b7080357 100644
--- a/versioned_docs/version-4.0/oauth2-examples-auth0.md
+++ b/versioned_docs/version-4.0/oauth2-examples-auth0.md
@@ -1,5 +1,5 @@
 ---
-title: Use https://auth0.com/ as Auth 2.0 server
+title: Use auth0.com as OAuth 2.0 Server
 displayed_sidebar: docsSidebar
 ---
 <!--
@@ -19,18 +19,18 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-# Use https://auth0.com/ as OAuth 2.0 server
+# Use [auth0.com](https://auth0.com) as OAuth 2.0 server
 
 This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Auth0 as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
 
-* Have an account in https://auth0.com/.
+* Have an [Auth0](https://auth0.com/) account.
 * Docker
 * A local clone of a [GitHub repository](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial) that contains all the configuration files and scripts used on this example
 
@@ -38,7 +38,7 @@ and Auth0 as Authorization Server using the following flows:
 
 In Auth0, resources are mapped to Application APIs.
 
-1. Once you have logged onto your account in https://auth0.com/, go to **dashboard > Applications > APIs > Create an API**.
+1. After logging into the Auth0 account, go to **dashboard > Applications > APIs > Create an API**.
 2. Give it the name `rabbitmq`. The important thing here is the `identifier` which must have the name of the *resource_server_id* we configured in RabbitMQ. This `identifier` goes into the `audience` JWT field. In our case, it is called `rabbitmq`.
 3. Choose `RS256` as the signing algorithm.
 4. Enable **RBAC**.
diff --git a/versioned_docs/version-4.0/oauth2-examples-entra-id/index.md b/versioned_docs/version-4.0/oauth2-examples-entra-id/index.md
index f737efdb4b..9ffec54cc9 100644
--- a/versioned_docs/version-4.0/oauth2-examples-entra-id/index.md
+++ b/versioned_docs/version-4.0/oauth2-examples-entra-id/index.md
@@ -48,7 +48,7 @@ When using **Entra ID as OAuth 2.0 server**, your client app (in our case Rabbit
 4. In the **Register an application** pane, provide the following information:
 
     * **Name**: the name you would like to give to your application (ex: *rabbitmq-oauth2*)
-    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (you can choose other options if you want to enlarge the audience of your app)
+    * **Supported Account Types**: select **Accounts in this organizational directory only (Default Directory only - Single tenant)** (this guide will focus on this option for simplicity)
     * On the **Select a platform** drop-down list, select **Single-page application (SPA)**
     * Configure the **Redirect URI** to: `https://localhost:15671/js/oidc-oauth/login-callback.html`
 
diff --git a/versioned_docs/version-4.0/oauth2-examples-keycloak.md b/versioned_docs/version-4.0/oauth2-examples-keycloak.md
index 12fd9982a8..b982b331d5 100644
--- a/versioned_docs/version-4.0/oauth2-examples-keycloak.md
+++ b/versioned_docs/version-4.0/oauth2-examples-keycloak.md
@@ -25,7 +25,7 @@ This guide explains how to set up OAuth 2.0 for RabbitMQ
 and Keycloak as Authorization Server using the following flows:
 
 * Access [management UI](./management/) via a browser
-* Access management rest api
+* Access management HTTP API
 * Application authentication and authorization
 
 ## Prerequisites to follow this guide
diff --git a/versioned_docs/version-4.0/oauth2-examples/index.md b/versioned_docs/version-4.0/oauth2-examples/index.md
index 9cab50979d..8e625dc25d 100644
--- a/versioned_docs/version-4.0/oauth2-examples/index.md
+++ b/versioned_docs/version-4.0/oauth2-examples/index.md
@@ -190,9 +190,9 @@ It is only when the user clicks **Click here to login** , the user is redirected
 
 ## Access other protocols using OAuth 2.0 tokens {#access-other-protocols}
 
-The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management rest api.
+The following subsections demonstrate how to use access tokens with any messaging protocol and also to access the management HTTP API.
 
-### Management REST api {#management-ui}
+### Management HTTP API {#management-ui}
 
 In this scenario a monitoring agent uses RabbitMQ HTTP API to collect monitoring information.
 Because it is not an end user, or human, you refer to it as a *service account*.
@@ -792,9 +792,9 @@ make start-rabbitmq
 **NOTE**: You do not need to run any OAuth 2.0 server like UAA. This is because you are creating a token and signing it using the same
 private-public key pair RabbitMQ is configured with.
 
-*Use a Rich Authorization Token to access the management rest api*
+*Use a Rich Authorization Token to access the management HTTP API*
 
-You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the management rest api.
+You are going use this token [jwts/rar-token.json](https://github.com/rabbitmq/rabbitmq-oauth2-tutorial/blob/main/jwts/rar-token.json) to access an endpoint of the Management HTTP API.
 
 ```bash
 make curl-with-token URL=http://localhost:15672/api/overview TOKEN=$(bin/jwt_token rar-token.json legacy-token-key private.pem public.pem)
diff --git a/versioned_docs/version-4.0/oauth2.md b/versioned_docs/version-4.0/oauth2.md
index 928eabab89..a971f3f63a 100644
--- a/versioned_docs/version-4.0/oauth2.md
+++ b/versioned_docs/version-4.0/oauth2.md
@@ -102,7 +102,7 @@ Based on the previous configuration, JWT Tokens presented to RabbitMQ for authen
 2. have a value in the `aud` field that matches `resource_server_id` value
 3. have scopes that must match the `resource_server_id` value, for example `new_resource_server_id.read:*/*`
 
-Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS url to download the signing keys.
+Also, the `https://my-oauth2-provider.com/realm/rabbitmq/.well-known/openid-configuration` endpoint must return the OpenID Provider Configuration which includes the JKWS URL to download the signing keys.
 :::info
 *.well-known/openid-configuration* is the OpenID standard path for the OpenID Provider Configuration endpoint
 :::
@@ -115,8 +115,8 @@ This plugin does not communicate with any OAuth 2.0 provider in order to authent
 
 Tokens must be digitally signed otherwise they are not accepted. RabbitMQ must have the signing key to validate the signature. You can either configure the signing keys the OAuth 2.0 provider will use, or configure RabbitMQ with one of the following two endpoints:
 
-  - **JWKS endpoint** - this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens.
-  - **OpenID Provider Configuration endpoint** - this is the endpoint that returns the provider's configuration including all its endpoints, such as the **JWKS endpoint**.
+* **JWKS endpoint**: this is the HTTP endpoint that returns the signing keys used to digitally sign the tokens.
+* **OpenID Provider Configuration endpoint**: this endpoint returns the provider's configuration including all of its endpoints, most importantly the **JWKS endpoint**
 
 When you configure RabbitMQ with one of two previous endpoints, RabbitMQ must make a HTTP request (or two, if we specify the latter endpoint) to download the signing keys. This is an operation that occurs once for any signing key not downloaded yet. When the OAuth 2.0 provider rotates the signing keys, newer tokens refer to a new signing key which RabbitMQ does not have yet which triggers another download of the newer signing keys.
 
@@ -137,25 +137,25 @@ In chronological order, here is the sequence of events that occur when a client
 |--------------------------------------------|-----------
 | `auth_oauth2.resource_server_id`           | The [Resource Server ID](#resource-server-id)
 | `auth_oauth2.resource_server_type`         | The Resource Server Type required when using [Rich Authorization Request](#rich-authorization-request) token format
-| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format). |
-| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character. |
-| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token.
-| `auth_oauth2.default_key`                  | ID of the default signing key.
-| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files).
-| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server that is used to discover endpoints such as `jwk_uri` and others (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
-| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https.
-| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint.
-| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the `issuer`.
-| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
-| `auth_oauth2.https.peer_verification`      | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable.
-| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`.
-| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`.
-| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false.
-| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support).
-| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`.
-| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration).
-| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration).
-| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing.
+| `auth_oauth2.additional_scopes_key`        | Configure the plugin to look for scopes in other fields (maps to `additional_rabbitmq_scopes` in the old format) |
+| `auth_oauth2.scope_prefix`                 | [Configure the prefix for all scopes](#scope-prefix). The default value is `auth_oauth2.resource_server_id` followed by the dot `.` character |
+| `auth_oauth2.preferred_username_claims`    | [List of the JWT claims](#preferred-username-claims) to look for the username associated with the token
+| `auth_oauth2.default_key`                  | ID of the default signing key
+| `auth_oauth2.signing_keys`                 | Paths to the [signing key files](#signing-key-files)
+| `auth_oauth2.issuer`                       | The [issuer URL](#configure-issuer) of the authorization server. Used to build the discovery endpoint URL to discover other endpoints such as such as `jwks_uri`. Management UI users will be sent to this for logging in
+| `auth_oauth2.jwks_url`                     | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema
+| `auth_oauth2.token_endpoint`               | The URL of the OAuth 2.0 token endpoint
+| `auth_oauth2.https.cacertfile`             | Path to a file containing PEM-encoded CA certificates. The CA certificates are used to connect to any of these endpoints: `jwks_url`, `token_endpoint`, or the `issuer`
+| `auth_oauth2.https.depth`                  | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10
+| `auth_oauth2.https.peer_verification`      | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set. <p/> **Deprecated**: This variable will be soon replaced by `auth_oauth2.https.verify`. Users should stop using this variable
+| `auth_oauth2.https.fail_if_no_peer_cert`   | Used together with `auth_oauth2.https.peer_verification = verify_peer`. When set to `true`, TLS connection will be rejected if the client fails to provide a certificate. The default value is `false`
+| `auth_oauth2.https.hostname_verification`  | Enable wildcard-aware hostname verification for key server. Available values: `wildcard`, `none`. The default value is `none`
+| `auth_oauth2.https.crl_check`              | [Perform CRL verification](https://www.erlang.org/doc/man/ssl#type-crl_check) (Certificate Revocation List) verification. Default value is false
+| `auth_oauth2.algorithms`                   | Restrict [the usable algorithms](https://github.com/potatosalad/erlang-jose#algorithm-support)
+| `auth_oauth2.verify_aud`                   | Whether to verify the [token's `aud`](#token-validation) field or not. The default value is `true`
+| `auth_oauth2.resource_servers`             | [Multiple OAuth 2.0 resources configuration](#multiple-resource-servers-configuration)
+| `auth_oauth2.oauth_providers`              | [Multiple OAuth 2.0 providers configuration](#multiple-oauth-providers-configuration)
+| `auth_oauth2.default_oauth_provider`       | ID of the OAuth 2.0 provider used for the `auth_oauth2.resource_servers`, that did not specify any (via the variable `oauth_provider_id`) or when `auth_oauth2.jwks_url` and `auth_oauth2.issuer` are both missing
 
 
 #### Resource Server ID {#resource-server-id}
@@ -256,7 +256,7 @@ Each `auth_oauth2.oauth_providers.{id/index}` entry has the following sub-keys.
 |------------------------------|-----------
 | `issuer`                     | URL of OAuth Provider. RabbitMQ uses this URL to build the OpenId Connect Discovery endpoint by appending the path `.well-known/openid-configuration` to this URL
 | `token_endpoint`             | The URL of the OAuth 2.0 token endpoint.
-| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must be https. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`.
+| `jwks_uri`                   | The URL of the [JWKS endpoint](#jwks-endpoint). According to the [JWT Specification](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.2), the endpoint URL must use "https" for schema. <p/>**Warning**: RabbitMQ uses for each OAuth Provider the variable name `jwks_uri` used by the OpenId Connect Discovery Specification rather than `jwks_url`.
 | `https.cacertfile`           | Path to a file containing PEM-encoded CA certificates used to connect `issuer` and/or `jwks_uri` URLs
 | `https.depth`                | The maximum number of non-self-issued intermediate certificates that may follow the peer certificate in a valid [certification path](ssl#peer-verification-depth). The default value is 10.
 | `https.verify`               | Configures [peer verification](ssl#peer-verification). Available values: `verify_none`, `verify_peer`. The default value is `verify_peer` if there are trusted CA installed in the OS or `auth_oauth2.https.cacertfile` is set.