diff --git a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc
index d45903a867056..bbadaae833d5b 100644
--- a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc
+++ b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc
@@ -3,24 +3,25 @@ This guide is maintained in the main Quarkus repository
 and pull requests should be submitted there:
 https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 ////
-= Using OpenID Connect (OIDC) Multi-Tenancy
+= Using OpenID Connect (OIDC) multitenancy
 include::_attributes.adoc[]
+:diataxis-type: howto
 :categories: security
 :keywords: sso oidc oauth2 security
-:summary: This guide demonstrates how your OpenID Connect application can support multi-tenancy so that you can serve multiple tenants from a single application.
 :topics: security,oidc,multitenancy
 :extensions: io.quarkus:quarkus-oidc
 
-This guide demonstrates how your OpenID Connect (OIDC) application can support multi-tenancy so that you can serve multiple tenants from a single application. Tenants can be distinct realms or security domains within the same OpenID Provider or even distinct OpenID Providers.
+This guide demonstrates how your OpenID Connect (OIDC) application can support multitenancy to serve multiple tenants from a single application.
+These tenants can have distinct realms or security domains within the same OIDC provider or even distinct OIDC providers.
 
-When serving multiple customers from the same application (e.g.: SaaS), each customer is a tenant. By enabling multi-tenancy support to your applications you are allowed to also support distinct authentication policies for each tenant even though if that means authenticating against different OpenID Providers, such as Keycloak and Google.
+Each customer functions as a distinct tenant when serving multiple customers from the same application, such as in a SaaS environment.
+By enabling multitenancy support to your applications, you can support distinct authentication policies for each tenant, even authenticating against different OIDC providers, such as Keycloak and Google.
 
-Please read the xref:security-oidc-bearer-token-authentication.adoc[OIDC Bearer token authentication] guide if you need to authorize a tenant using Bearer Token Authorization.
+To authorize a tenant by using Bearer Token Authorization, see the xref:security-oidc-bearer-token-authentication.adoc[OpenID Connect (OIDC) Bearer token authentication] guide.
 
-If you need to authenticate and authorize a tenant using OpenID Connect Authorization Code Flow, read the xref:security-oidc-code-flow-authentication.adoc[OIDC code flow mechanism for protecting web applications] guide.
-
-Also see the xref:security-oidc-configuration-properties-reference.adoc[OIDC configuration properties] reference guide.
+To authenticate and authorize a tenant by using the OIDC authorization code flow, read the xref:security-oidc-code-flow-authentication.adoc[OpenID Connect authorization code flow mechanism for protecting web applications] guide.
 
+Also, see the xref:security-oidc-configuration-properties-reference.adoc[OpenID Connect (OIDC) configuration properties] reference guide.
 
 == Prerequisites
 
@@ -30,40 +31,40 @@ include::{includes}/prerequisites.adoc[]
 
 == Architecture
 
-In this example, we build a very simple application which supports two resource methods:
+In this example, we build a very simple application that supports two resource methods:
 
 * `/{tenant}`
 
-This resource returns information obtained from the ID token issued by OpenID Provider about the authenticated user and the current tenant.
+This resource returns information obtained from the ID token issued by the OIDC provider about the authenticated user and the current tenant.
 
-* `/{tenant}`/bearer
+* `/{tenant}/bearer`
 
-This resource returns information obtained from the Access token issued by OpenID Provider about the authenticated user and the current tenant.
+This resource returns information obtained from the Access Token issued by the OIDC provider about the authenticated user and the current tenant.
 
 == Solution
 
-We recommend that you follow the instructions in the next sections and create the application step by step.
+We recommend you follow the instructions in the next sections and create the application step by step.
 However, you can go right to the completed example.
 
 Clone the Git repository: `git clone {quickstarts-clone-url}`, or download an {quickstarts-archive-url}[archive].
 
 The solution is located in the `security-openid-connect-multi-tenancy-quickstart` link:{quickstarts-tree-url}/security-openid-connect-multi-tenancy-quickstart[directory].
 
-== Creating the Maven Project
+== Creating the Maven project
 
-First, we need a new project. Create a new project with the following command:
+First, we need a new project.
+Create a new project with the following command:
 
 :create-app-artifact-id: security-openid-connect-multi-tenancy-quickstart
 :create-app-extensions: oidc,resteasy-reactive-jackson
 include::{includes}/devtools/create-app.adoc[]
 
-If you already have your Quarkus project configured, you can add the `oidc` extension
-to your project by running the following command in your project base directory:
+If you already have your Quarkus project configured, add the `oidc` extension to your project by running the following command in your project base directory:
 
 :add-extension-extensions: oidc
 include::{includes}/devtools/extension-add.adoc[]
 
-This will add the following to your build file:
+This adds the following to your build file:
 
 [source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"]
 .pom.xml
@@ -82,7 +83,8 @@ implementation("io.quarkus:quarkus-oidc")
 
 == Writing the application
 
-Let's start by implementing the `/{tenant}` endpoint. As you can see from the source code below it is just a regular Jakarta REST resource:
+Start by implementing the `/{tenant}` endpoint.
+As you can see from the source code below, it is just a regular Jakarta REST resource:
 
 [source,java]
 ----
@@ -100,21 +102,22 @@ import io.quarkus.oidc.IdToken;
 @Path("/{tenant}")
 public class HomeResource {
     /**
-     * Injection point for the ID Token issued by the OpenID Connect Provider
+     * Injection point for the ID Token issued by the OIDC provider.
      */
     @Inject
     @IdToken
     JsonWebToken idToken;
 
     /**
-     * Injection point for the Access Token issued by the OpenID Connect Provider
+     * Injection point for the Access Token issued by the OIDC provider.
      */
     @Inject
     JsonWebToken accessToken;
 
     /**
-     * Returns the ID Token info. This endpoint exists only for demonstration purposes, you should not
-     * expose this token in a real application.
+     * Returns the ID Token info.
+     * This endpoint exists only for demonstration purposes.
+     * Do not expose this token in a real application.
      *
      * @return ID Token info
      */
@@ -131,8 +134,9 @@ public class HomeResource {
     }
 
     /**
-     * Returns the Access Token info. This endpoint exists only for demonstration purposes, you should not
-     * expose this token in a real application.
+     * Returns the Access Token info.
+     * This endpoint exists only for demonstration purposes.
+     * Do not expose this token in a real application.
      *
      * @return Access Token info
      */
@@ -152,7 +156,7 @@ public class HomeResource {
 
 ----
 
-In order to resolve the tenant from incoming requests and map it to a specific `quarkus-oidc` tenant configuration in application.properties, you need to create an implementation for the `io.quarkus.oidc.TenantConfigResolver` interface which can be used to resolve the tenant configurations dynamically:
+To resolve the tenant from incoming requests and map it to a specific `quarkus-oidc` tenant configuration in `application.properties`, create an implementation for the `io.quarkus.oidc.TenantConfigResolver` interface, which can dynamically resolve tenant configurations:
 
 [source,java]
 ----
@@ -194,52 +198,56 @@ public class CustomTenantResolver implements TenantConfigResolver {
 }
 ----
 
-From the implementation above, tenants are resolved from the request path so that in case no tenant could be inferred, `null` is returned to indicate that the default tenant configuration should be used.
+In the preceding implementation, tenants are resolved from the request path.
+If no tenant can be inferred, `null` is returned to indicate that the default tenant configuration should be used.
 
-Note the `tenant-a` application type is `hybrid` - it can accept HTTP bearer tokens if provided, otherwise it will initiate an authorization code flow when the authentication is required.
+The `tenant-a` application type is `hybrid`; it can accept HTTP bearer tokens if provided.
+Otherwise, it initiates an authorization code flow when authentication is required.
 
 == Configuring the application
 
 [source,properties]
 ----
-# Default Tenant Configuration
+# Default tenant configuration
 %prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
 quarkus.oidc.client-id=multi-tenant-client
 quarkus.oidc.application-type=web-app
 
-# Tenant A Configuration is created dynamically in CustomTenantConfigResolver
+# Tenant A configuration is created dynamically in CustomTenantConfigResolver
 
-# HTTP Security Configuration
+# HTTP security configuration
 quarkus.http.auth.permission.authenticated.paths=/*
 quarkus.http.auth.permission.authenticated.policy=authenticated
 ----
 
-The first configuration is the default tenant configuration that should be used when the tenant can not be inferred from the request. Note that a `%prod` profile prefix is used with `quarkus.oidc.auth-server-url` - it is done to support testing a multi-tenant application with `Dev Services For Keycloak`. This configuration is using a Keycloak instance to authenticate users.
+The first configuration is the default tenant configuration that should be used when the tenant cannot be inferred from the request.
+Be aware that a `%prod` profile prefix is used with `quarkus.oidc.auth-server-url` to support testing a multitenant application with Dev Services For Keycloak.
+This configuration uses a Keycloak instance to authenticate users.
 
-The second configuration is provided by `TenantConfigResolver`, it is the configuration that will be used when an incoming request is mapped to the tenant `tenant-a`.
+The second configuration, provided by `TenantConfigResolver`, is used when an incoming request is mapped to the `tenant-a` tenant.
 
-Note that both configurations map to the same Keycloak server instance while using distinct `realms`.
+Both configurations map to the same Keycloak server instance while using distinct `realms`.
 
-Alternatively you can configure the tenant `tenant-a` directly in `application.properties`:
+Alternatively, you can configure the tenant `tenant-a` directly in `application.properties`:
 
 [source,properties]
 ----
-# Default Tenant Configuration
+# Default tenant configuration
 %prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
 quarkus.oidc.client-id=multi-tenant-client
 quarkus.oidc.application-type=web-app
 
-# Tenant A Configuration
+# Tenant A configuration
 quarkus.oidc.tenant-a.auth-server-url=http://localhost:8180/realms/tenant-a
 quarkus.oidc.tenant-a.client-id=multi-tenant-client
 quarkus.oidc.tenant-a.application-type=web-app
 
-# HTTP Security Configuration
+# HTTP security configuration
 quarkus.http.auth.permission.authenticated.paths=/*
 quarkus.http.auth.permission.authenticated.policy=authenticated
 ----
 
-and use a custom `TenantConfigResolver` to resolve it:
+And use a custom `TenantConfigResolver` to resolve it:
 
 [source,java]
 ----
@@ -259,7 +267,7 @@ public class CustomTenantResolver implements TenantResolver {
         String[] parts = path.split("/");
 
         if (parts.length == 0) {
-            // resolve to default tenant configuration
+            //Resolve to default tenant configuration
             return null;
         }
 
@@ -268,14 +276,29 @@ public class CustomTenantResolver implements TenantResolver {
 }
 ----
 
-You can define multiple tenants in your configuration file, just make sure they have a unique alias so that you can map them properly when resolving a tenant from your `TenantResolver` implementation.
+You can define multiple tenants in your configuration file.
+To map them correctly when resolving a tenant from your `TenantResolver` implementation, ensure each has a unique alias.
 
-However, using a static tenant resolution (configuring tenants in `application.properties` and resolving them with `TenantResolver`) prevents testing the endpoint with `Dev Services for Keycloak` since `Dev Services for Keycloak` has no knowledge of how the requests will be mapped to individual tenants and can not dynamically provide tenant-specific `quarkus.oidc.<tenant-id>.auth-server-url` values and therefore using `%prod` prefixes with the tenant-specific URLs in `application.properties` will not work in test or dev mode.
+However, using a static tenant resolution method, such as configuring tenants in `application.properties` and resolving them with `TenantResolver`, presents limitations.
+This approach is incompatible with testing the endpoint with Dev Services for Keycloak.
+The reason is that Dev Services for Keycloak has no knowledge of how requests are mapped to individual tenants.
+Therefore, it cannot dynamically provide tenant-specific `quarkus.oidc.<tenant-id>.auth-server-url` values.
+As a result, using `%prod` prefixes with the tenant-specific URLs in `application.properties` is ineffective in tests or development mode.
 
 [NOTE]
 ====
-When a current tenant represents an OIDC `web-app` application, the current `io.vertx.ext.web.RoutingContext` will contain a `tenant-id` attribute by the time the custom tenant resolver has been called for all the requests completing the code authentication flow and the already authenticated requests, when either a tenant specific state or session cookie already exists.
-Therefore, when working with multiple OpenID Connect Providers, you only need a path specific check to resolve a tenant id if the `RoutingContext` does not have the `tenant-id` attribute set, for example:
+When a current tenant represents an OIDC `web-app` application, the current `io.vertx.ext.web.RoutingContext` contains a `tenant-id` attribute by the time the custom tenant resolver has been called for all the requests completing the code authentication flow and the already authenticated requests, when either a tenant-specific state or session cookie already exists.
+Therefore, when working with multiple OIDC providers, you only need a path-specific check to resolve a tenant ID if the `RoutingContext` does not have the `tenant-id` attribute set, for example:
+
+// When dealing with an OIDC `web-app` application as the current tenant, the process involves specific attributes and contexts.
+// In this scenario, the `io.vertx.ext.web.RoutingContext` of the current tenant contains a `tenant-id` attribute.
+// This inclusion occurs by the time the custom tenant resolver is called.
+// It applies to all requests that complete the code authentication flow and to already authenticated requests.
+// This authentication is recognized when a tenant-specific state or session cookie already exists.
+//
+// Therefore, when working with multiple OIDC providers, resolving a tenant ID requires careful consideration.
+// Specifically, a path-specific check becomes necessary only if the `RoutingContext` lacks the `tenant-id` attribute.
+// For example:
 
 [source,java]
 ----
@@ -300,7 +323,7 @@ public class CustomTenantResolver implements TenantResolver {
             String[] parts = path.split("/");
 
             if (parts.length == 0) {
-                // resolve to default tenant configuration
+                //Resolve to default tenant configuration
                 return null;
             }
             return parts[1];
@@ -309,17 +332,24 @@ public class CustomTenantResolver implements TenantResolver {
 }
 ----
 
-In fact, this is how Quarkus OIDC resolves static custom tenants itself if no custom `TenantResolver` is registered.
+This is how Quarkus OIDC resolves static custom tenants if no custom `TenantResolver` is registered.
 
-A similar technique can be used with `TenantConfigResolver` where a `tenant-id` provided in the context can be used to return `OidcTenantConfig` already prepared with the previous request.
+A similar technique can be used with `TenantConfigResolver` where a `tenant-id` provided in the context can return `OidcTenantConfig` already prepared with the previous request.
 ====
 
 [NOTE]
 ====
 If you also use xref:hibernate-orm.adoc#multitenancy[Hibernate ORM multitenancy] or xref:mongodb-panache.adoc#multitenancy[MongoDB with Panache multitenancy] and both tenant IDs are the same
-and must be extracted from the Vert.x `RoutingContext` you can pass the tenant id from the OIDC Tenant Resolver to the Hibernate ORM Tenant Resolver or MongoDB with Panache Mongo Database Resolver
+and must be extracted from the Vert.x `RoutingContext`, you can pass the tenant ID from the OIDC Tenant Resolver to the Hibernate ORM Tenant Resolver or MongoDB with Panache Mongo Database Resolver
 as a `RoutingContext` attribute, for example:
 
+// If you use xref:hibernate-orm.adoc#multitenancy[Hibernate ORM multitenancy] or xref:mongodb-panache.adoc#multitenancy[MongoDB with Panache multitenancy], and both tenant IDs are the same, a specific process is required.
+// These tenant IDs must be extracted from the Vert.x `RoutingContext`.
+// In such cases, you can facilitate communication between different systems.
+// This is done by passing the tenant ID from the OIDC Tenant Resolver directly to either the Hibernate ORM Tenant Resolver or the MongoDB with Panache Mongo Database Resolver.
+// The transfer is achieved using a `RoutingContext` attribute.
+// For example:
+
 [source,java]
 ----
 public class CustomTenantResolver implements TenantResolver {
@@ -334,41 +364,42 @@ public class CustomTenantResolver implements TenantResolver {
 ----
 ====
 
-== Starting and Configuring the Keycloak Server
+== Starting and configuring the Keycloak server
 
-To start a Keycloak Server you can use Docker and just run the following command:
+To start a Keycloak server, you can use Docker and run the following command:
 
 [source,bash,subs=attributes+]
 ----
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev
 ----
 
-where `keycloak.version` should be set to `17.0.0` or higher.
+Where `keycloak.version` is set to `23.0.0` or higher.
 
-You should be able to access your Keycloak Server at http://localhost:8180[localhost:8180].
+Access your Keycloak server at http://localhost:8180[localhost:8180].
 
-Log in as the `admin` user to access the Keycloak Administration Console. Username should be `admin` and password `admin`.
+Log in as the `admin` user to access the Keycloak administration console.
+The username and password are both `admin`.
 
-Now, follow the steps below to import the realms for the two tenants:
+Now, import the realms for the two tenants:
 
-* Import the link:{quickstarts-tree-url}/security-openid-connect-multi-tenancy-quickstart/config/default-tenant-realm.json[default-tenant-realm.json] to create the default realm
+* Import the link:{quickstarts-tree-url}/security-openid-connect-multi-tenancy-quickstart/config/default-tenant-realm.json[default-tenant-realm.json] to create the default realm.
 * Import the link:{quickstarts-tree-url}/security-openid-connect-multi-tenancy-quickstart/config/tenant-a-realm.json[tenant-a-realm.json] to create the realm for the tenant `tenant-a`.
 
-For more details, see the Keycloak documentation about how to https://www.keycloak.org/docs/latest/server_admin/index.html#_create-realm[create a new realm].
+For more information, see the Keycloak documentation about how to https://www.keycloak.org/docs/latest/server_admin/index.html#_create-realm[create a new realm].
 
-== Running and Using the Application
+== Running and using the application
 
-=== Running in Developer Mode
+=== Running in developer mode
 
 To run the microservice in dev mode, use:
 
 include::{includes}/devtools/dev.adoc[]
 
-=== Running in JVM Mode
+=== Running in JVM mode
 
-When you're done playing with dev mode, you can run it as a standard Java application.
+After exploring the application in dev mode, you can run it as a standard Java application.
 
-First compile it:
+First, compile it:
 
 include::{includes}/devtools/build.adoc[]
 
@@ -379,35 +410,34 @@ Then run it:
 java -jar target/quarkus-app/quarkus-run.jar
 ----
 
-=== Running in Native Mode
+=== Running in native mode
 
-This same demo can be compiled into native code: no modifications required.
+This same demo can be compiled into native code; no modifications are required.
 
 This implies that you no longer need to install a JVM on your
 production environment, as the runtime technology is included in
-the produced binary, and optimized to run with minimal resource overhead.
+the produced binary, and optimized to run with minimal resources.
 
-Compilation will take a bit longer, so this step is disabled by default;
+Compilation takes a bit longer, so this step is turned off by default;
 let's build again by enabling the native build:
 
 include::{includes}/devtools/build-native.adoc[]
 
-After getting a cup of coffee, you'll be able to run this binary directly:
+After a little while, you can run this binary directly:
 
 [source,bash]
 ----
 ./target/security-openid-connect-multi-tenancy-quickstart-runner
 ----
 
-== Test the Application
+== Test the application
 
 === Use Dev Services for Keycloak
 
 Using xref:security-openid-connect-dev-services.adoc[Dev Services for Keycloak] is recommended for the integration testing against Keycloak.
-`Dev Services for Keycloak` will launch and initialize a test container: it will import configured realms and set a base Keycloak URL for `CustomTenantResolver` used in this quickstart to calculate a realm specific URL.
-
+Dev Services for Keycloak launches and initializes a test container: it imports configured realms and sets a base Keycloak URL for the `CustomTenantResolver` to calculate a realm-specific URL.
 
-First you need to add the following dependencies:
+First, add the following dependencies:
 
 [source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"]
 .pom.xml
@@ -438,27 +468,27 @@ testImplementation("net.sourceforge.htmlunit:htmlunit")
 ----
 
 `quarkus-test-keycloak-server` provides a utility class `io.quarkus.test.keycloak.client.KeycloakTestClient` for acquiring the realm specific access tokens and which you can use with `RestAssured` for testing the `/{tenant}/bearer` endpoint expecting bearer access tokens.
-`HtmlUnit` is used for testing the `/{tenant}` endpoint and the authorization code flow.
+`HtmlUnit` tests the `/{tenant}` endpoint and the authorization code flow.
 
 Next, configure the required realms:
 
 [source,properties]
 ----
-# Default Tenant Configuration
+# Default tenant configuration
 %prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
 quarkus.oidc.client-id=multi-tenant-client
 quarkus.oidc.application-type=web-app
 
-# Tenant A Configuration is created dynamically in CustomTenantConfigResolver
+# Tenant A configuration is created dynamically in CustomTenantConfigResolver
 
-# HTTP Security Configuration
+# HTTP security configuration
 quarkus.http.auth.permission.authenticated.paths=/*
 quarkus.http.auth.permission.authenticated.policy=authenticated
 
 quarkus.keycloak.devservices.realm-path=default-tenant-realm.json,tenant-a-realm.json
 ----
 
-Finally, write your test which will be executed in JVM mode:
+Finally, write your test, which runs in JVM mode:
 
 [source,java]
 ----
@@ -540,7 +570,7 @@ public class CodeFlowTest {
 }
 ----
 
-and in native mode:
+In native mode:
 
 [source,java]
 ----
@@ -553,32 +583,34 @@ public class CodeFlowIT extends CodeFlowTest {
 }
 ----
 
-Please see xref:security-openid-connect-dev-services.adoc[Dev Services for Keycloak] for more information about the way it is initialized and configured.
+For more information about how it is initialized and configured, see xref:security-openid-connect-dev-services.adoc[Dev Services for Keycloak].
 
-=== Use Browser
+=== Use the browser
 
-To test the application, you should open your browser and access the following URL:
+To test the application, open your browser and access the following URL:
 
 * http://localhost:8080/default[http://localhost:8080/default]
 
-If everything is working as expected, you should be redirected to the Keycloak server to authenticate. Note that the requested path
-defines a `default` tenant which we don't have mapped in the configuration file. In this case, the default configuration will be used.
+If everything works as expected, you are redirected to the Keycloak server to authenticate.
+Be aware that the requested path defines a `default` tenant, which we don't have mapped in the configuration file.
+In this case, the default configuration is used.
 
-In order to authenticate to the application you should type the following credentials when at the Keycloak login page:
+To authenticate to the application, enter the following credentials in the Keycloak login page:
 
-* Username: *alice*
-* Password: *alice*
+* Username: `alice`
+* Password: `alice`
 
-After clicking the `Login` button you should be redirected back to the application.
+After clicking the *Login* button, you are redirected back to the application.
 
 If you try now to access the application at the following URL:
 
 * http://localhost:8080/tenant-a[http://localhost:8080/tenant-a]
 
-You should be redirected again to the login page at Keycloak. However, now you are going to authenticate using a different `realm`.
+You are redirected again to the Keycloak login page.
+However, now you are going to authenticate by using a different `realm`.
 
-In both cases, if the user is successfully authenticated, the landing page will show the user's name and e-mail. Even though
-user `alice` exists in both tenants, for the application they are distinct users belonging to different realms/tenants.
+In both cases, the landing page shows the user's name and email if the user is successfully authenticated.
+Although `alice` exists in both tenants, the application treats them as distinct users in separate realms or tenants.
 
 [[static-tenant-resolution]]
 == Static tenant configuration resolution
@@ -590,11 +622,11 @@ To configure the resolution of the tenant identifier, use one of the following o
 * <<default-tenant-resolver>>
 * <<annotations-tenant-resolver>>
 
-These tenant resolution options will be tried in turn, in the order they are listed, until the tenant id gets resolved.
-If the tenant id remains unresolved (`null`) in the end then the default (unnamed) tenant configuration will be selected.
+These tenant resolution options are tried in the order they are listed until the tenant ID gets resolved.
+If the tenant ID remains unresolved (`null`), the default (unnamed) tenant configuration is selected.
 
 [[tenant-resolver]]
-=== Resolve with `TenantResolver`
+=== Resolve with TenantResolver
 
 The following `application.properties` example shows how you can resolve the tenant identifier of two tenants named `a` and `b` by using the `TenantResolver` method:
 
@@ -639,7 +671,7 @@ In this example, the value of the last request path segment is a tenant ID, but
 [[default-tenant-resolver]]
 === Default resolution
 
-The default resolution for a tenant identifier is convention based, whereby the authentication request must include the tenant identifier in the last segment of the request path.
+The default resolution for a tenant identifier is convention-based, whereby the authentication request must include the tenant identifier in the last segment of the request path.
 
 The following `application.properties` example shows how you can configure two tenants named `google` and `github`:
 
@@ -658,8 +690,9 @@ quarkus.oidc.github.credentials.secret=${github-client-secret}
 quarkus.oidc.github.authentication.redirect-path=/signed-in
 ----
 
-In this example, both tenants configure OIDC `web-app` applications to use an authorization code flow to authenticate users and also require session cookies to get generated after the authentication has taken place.
-After either Google or GitHub authenticates the current user, the user gets returned to the `/signed-in` area for authenticated users, for example, a secured resource path on the JAX-RS endpoint.
+In the provided example, both tenants configure OIDC `web-app` applications to use an authorization code flow to authenticate users.
+Additionally, both tenants require session cookies to be generated after authentication.
+After Google or GitHub authenticates the current user, the user gets returned to the `/signed-in` area for authenticated users, such as a secured resource path on the JAX-RS endpoint.
 
 Finally, to complete the default tenant resolution, set the following configuration property:
 
@@ -669,11 +702,12 @@ quarkus.http.auth.permission.login.paths=/google,/github
 quarkus.http.auth.permission.login.policy=authenticated
 ----
 
-If the endpoint is running on `http://localhost:8080`, you can also provide UI options for users to log in to either `http://localhost:8080/google` or `http://localhost:8080/github`, without having to add specific`/google` or `/github` JAX-RS resource paths.
+If the endpoint is running on `http://localhost:8080`, you can also provide UI options for users to log in to either `http://localhost:8080/google` or `http://localhost:8080/github`, without having to add specific `/google` or `/github` JAX-RS resource paths.
 Tenant identifiers are also recorded in the session cookie names after the authentication is completed.
 Therefore, authenticated users can access the secured application area without requiring either the `google` or `github` path values to be included in the secured URL.
 
-Default resolution can also work for Bearer token authentication but it might be less practical in this case because a tenant identifier will always need to be set as the last path segment value.
+Default resolution can also work for Bearer token authentication.
+Still, it might be less practical because a tenant identifier must always be set as the last path segment value.
 
 [[annotations-tenant-resolver]]
 === Resolve with annotations
@@ -682,12 +716,12 @@ You can use the `io.quarkus.oidc.Tenant` annotation for resolving the tenant ide
 
 [NOTE]
 ====
-Proactive HTTP authentication must be disabled (`quarkus.http.auth.proactive=false`) for this to work. For more information, see xref:security-proactive-authentication.adoc[Proactive authentication].
+Proactive HTTP authentication must be disabled (`quarkus.http.auth.proactive=false`) for this to work.
+For more information, see the xref:security-proactive-authentication.adoc[Proactive authentication] guide.
 ====
 
-Assuming your application supports two OIDC tenants (`hr`, and default), all resource methods and classes
-carrying `@Tenant("hr")` will be authenticated using the OIDC provider configured by `quarkus.oidc.hr.auth-server-url`,
-while all other classes and methods will still be authenticated using the default OIDC provider.
+Assuming your application supports two OIDC tenants, the `hr` and default tenants, all resource methods and classes carrying `@Tenant("hr")` are authenticated by using the OIDC provider configured by `quarkus.oidc.hr.auth-server-url`.
+In contrast, all other classes and methods are still authenticated by using the default OIDC provider.
 
 [source,java]
 ----
@@ -711,7 +745,7 @@ public class HelloResource {
     }
 }
 ----
-<1> The `io.quarkus.oidc.Tenant` annotation must be placed either on resource class or resource method.
+<1> The `io.quarkus.oidc.Tenant` annotation must be placed on either the resource class or resource method.
 
 [[tenant-config-resolver]]
 == Dynamic tenant configuration resolution
@@ -743,17 +777,17 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
         String[] parts = path.split("/");
 
         if (parts.length == 0) {
-            // resolve to default tenant configuration
+            //Resolve to default tenant configuration
             return null;
         }
 
         if ("tenant-c".equals(parts[1])) {
             // Do 'return requestContext.runBlocking(createTenantConfig());'
-            // if a blocking call is required to create a tenant config
+            // if a blocking call is required to create a tenant config,
             return Uni.createFromItem(createTenantConfig());
         }
 
-        // resolve to default tenant configuration
+        //Resolve to default tenant configuration
         return null;
     }
 
@@ -769,36 +803,41 @@ public class CustomTenantConfigResolver implements TenantConfigResolver {
 
         config.setCredentials(credentials);
 
-        // any other setting support by the quarkus-oidc extension
+        // Any other setting supported by the quarkus-oidc extension
 
         return () -> config;
     }
 }
 ----
 
-The `OidcTenantConfig` returned from this method is the same used to parse the `oidc` namespace configuration from the `application.properties`. You can populate it using any of the settings supported by the `quarkus-oidc` extension.
+The `OidcTenantConfig` returned by this method is the same one used to parse the `oidc` namespace configuration from the `application.properties`.
+You can populate it by using any settings supported by the `quarkus-oidc` extension.
 
-If the dynamic tenant resolver returns `null` then a <<static-tenant-resolution>> will be attempted next.
+If the dynamic tenant resolver returns `null`, a <<static-tenant-resolution>> is attempted next.
 
-=== Tenant resolution for OIDC `web-app` applications
+=== Tenant resolution for OIDC web-app applications
 
-The simplest option for resolving OIDC `web-app` application configuration is to follow the steps described in the <<default-tenant-resolver>> section.
+The simplest option for resolving the OIDC `web-app` application configuration is to follow the steps described in the <<default-tenant-resolver>> section.
 
-Try one of the options suggested below if the default resolution strategy does not work for your application setup.
+Try one of the options below if the default resolution strategy does not work for your application setup.
 
-Several options are available for selecting the tenant configuration which should be used to secure the current HTTP request for both `service` and `web-app` OIDC applications, such as:
+Several options are available for selecting the tenant configuration that should be used to secure the current HTTP request for both `service` and `web-app` OIDC applications, such as:
 
-- Check URL paths, for example, a `tenant-service` configuration has to be used for the "/service" paths, while a `tenant-manage` configuration - for the "/management" paths
-- Check HTTP headers, for example, with a URL path always being '/service', a header such as "Realm: service" or "Realm: management" can help to select between the `tenant-service` and `tenant-manage` configurations
-- Check URL query parameters - it can work similarly to the way the headers are used to select the tenant configuration
+- Check the URL paths.
+For example, a `tenant-service` configuration must be used for the `/service` paths, while a `tenant-manage` configuration must be used for the `/management` paths.
+- Check the HTTP headers.
+For example, with a URL path always being `/service`, a header such as `Realm: service` or `Realm: management` can help to select between the `tenant-service` and `tenant-manage` configurations.
+- Check the URL query parameters.
+It can work similarly to the way the headers are used to select the tenant configuration.
 
 All these options can be easily implemented with the custom `TenantResolver` and `TenantConfigResolver` implementations for the OIDC `service` applications.
 
-However, due to an HTTP redirect required to complete the code authentication flow for the OIDC `web-app` applications, a custom HTTP cookie may be needed to select the same tenant configuration before and after this redirect request because:
+However, due to an HTTP redirect required to complete the code authentication flow for the OIDC `web-app` applications, a custom HTTP cookie might be needed to select the same tenant configuration before and after this redirect request because:
 
-- URL path may not be the same after the redirect request if a single redirect URL has been registered in the OIDC Provider - the original request path can be restored but after the tenant configuration is resolved
-- HTTP headers used during the original request are not available after the redirect
-- Custom URL query parameters are restored after the redirect but after the tenant configuration is resolved
+- The URL path might not be the same after the redirect request if a single redirect URL has been registered in the OIDC provider.
+The original request path can be restored after the tenant configuration has been resolved.
+- The HTTP headers used during the original request are unavailable after the redirect.
+- The custom URL query parameters are restored after the redirect but only after the tenant configuration is resolved.
 
 One option to ensure the information for resolving the tenant configurations for `web-app` applications is available before and after the redirect is to use a cookie, for example:
 
@@ -834,20 +873,20 @@ public class CustomTenantResolver implements TenantResolver {
 ----
 
 [[disable-tenant]]
-== Disabling Tenant Configurations
+== Disabling tenant configurations
 
-Custom `TenantResolver` and `TenantConfigResolver` implementations may return `null` if no tenant can be inferred from the current request and a fallback to the default tenant configuration is required.
+Custom `TenantResolver` and `TenantConfigResolver` implementations might return `null` if no tenant can be inferred from the current request and a fallback to the default tenant configuration is required.
 
-If you expect that the custom resolvers will always infer a tenant then you do not need to configure the default tenant resolution.
+If you expect the custom resolvers to always infer a tenant, you do not need to configure the default tenant resolution.
 
-* To disable the default tenant configuration, set  `quarkus.oidc.tenant-enabled=false`.
+* To turn off the default tenant configuration, set  `quarkus.oidc.tenant-enabled=false`.
 
 [NOTE]
 ====
-The default tenant configuration is automatically disabled when `quarkus.oidc.auth-server-url` is not configured but either custom tenant configurations are available or `TenantConfigResolver` is registered.
+The default tenant configuration is automatically disabled when `quarkus.oidc.auth-server-url` is not configured, but either custom tenant configurations are available or `TenantConfigResolver` is registered.
 ====
 
-Note that tenant specific configurations can also be disabled, for example: `quarkus.oidc.tenant-a.tenant-enabled=false`.
+Be aware that tenant-specific configurations can also be disabled, for example: `quarkus.oidc.tenant-a.tenant-enabled=false`.
 
 == References