Use title badges

configuration/authorization-storage.md

@@ -134,7 +134,7 @@ In the same vein, ad-hoc authorizations are also created when a refresh token is
 > removed from the database after a short period of time (14 days by default). Unlike ad-hoc authorizations, permanent authorizations
 > are never removed from the database.
 
-## Enabling authorization entry validation at the API level (validation-only)
+## Enabling authorization entry validation at the API level <Badge type="tip" text="validation" />
 
 **For performance reasons, OpenIddict 3.0 doesn't check, by default, the status of an authorization entry when receiving an API request**: access tokens are considered
 valid even if the attached authorization was revoked. For scenarios that require immediate authorization revocation, the OpenIddict validation handler can be configured
@@ -155,7 +155,7 @@ services.AddOpenIddict()
     });
 ```
 
-## Disabling authorization storage (server-only)
+## Disabling authorization storage <Badge type="danger" text="server" />
 
 While STRONGLY discouraged, authorization storage can be disabled in the server options:
 

configuration/proof-key-for-code-exchange.md

@@ -7,7 +7,7 @@ confidential clients to help mitigate authorization code leakages.
 This mechanism is fully supported by all versions of the OpenIddict server stack and can be
 enforced globally or per-client to block authorization requests that don't send PKCE parameters.
 
-## Enabling PKCE enforcement at the global level (server-only)
+## Enabling PKCE enforcement at the global level <Badge type="danger" text="server" />
 
 Proof Key for Code Exchange can be enforced globally by calling `options.RequireProofKeyForCodeExchange()` in the server options:
 
@@ -19,7 +19,7 @@ services.AddOpenIddict()
     });
 ```
 
-## Enabling PKCE enforcement per client (server-only)
+## Enabling PKCE enforcement per client <Badge type="danger" text="server" />
 
 Proof Key for Code Exchange can also be enforced per-client by adding it to the list of requirements attached to a client:
 

configuration/token-storage.md

@@ -18,7 +18,7 @@ when communicating with OpenIddict's endpoints or with resource servers (if refe
 > In OpenIddict 3.0+, the ability to revoke a token is not tied to the token format and doesn't require enabling reference tokens:
 > regular JWT or ASP.NET Core Data Protection tokens can be revoked as long as token storage is not explicitly disabled in the server options.
 
-## Enabling reference access and/or refresh tokens (server-only)
+## Enabling reference access and/or refresh tokens <Badge type="danger" text="server" />
 
 Reference access and refresh tokens can be manually enabled in the server options for developers who prefer returning
 shorter access and/or refresh tokens or need to deal with limits that would prevent sending large tokens over the wire.
@@ -38,7 +38,7 @@ services.AddOpenIddict()
     });
 ```
 
-## Enabling token entry validation at the API level (validation-only)
+## Enabling token entry validation at the API level <Badge type="tip" text="validation" />
 
 **For performance reasons, OpenIddict 3.0 doesn't check, by default, the status of a token entry when receiving an API request**: access tokens are considered valid until they expire.
 For scenarios that require immediate access token revocation, the OpenIddict validation handler can be configured to enforce token entry validation for each API request:
@@ -57,7 +57,7 @@ services.AddOpenIddict()
     });
 ```
 
-## Disabling token storage (server-only)
+## Disabling token storage <Badge type="danger" text="server" />
 
 While STRONGLY discouraged, token storage can be disabled in the server options:
 

integrations/aspnet-core.md

@@ -96,7 +96,7 @@ services.AddOpenIddict()
 
 ## Advanced configuration
 
-### Transport security requirement (client and server)
+### Transport security requirement <Badge type="warning" text="client" /><Badge type="danger" text="server" />
 
 By default, the OpenIddict server ASP.NET Core integration will refuse to serve non-HTTPS
 requests for security reasons and will return an error page to the caller.
@@ -128,7 +128,7 @@ services.AddOpenIddict()
 > For more information,
 > read [Configure ASP.NET Core to work with proxy servers and load balancers](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer).
 
-### Pass-through mode (client and server)
+### Pass-through mode <Badge type="warning" text="client" /><Badge type="danger" text="server" />
 
 The OpenIddict client and server stacks offer built-in pass-through support for some of
 their endpoints (typically, endpoints for which users will want to provide custom logic).
@@ -188,7 +188,7 @@ app.MapMethods("authorize", [HttpMethods.Get, HttpMethods.Post], async (HttpCont
 });
 ```
 
-### Status code pages middleware integration (client and server)
+### Status code pages middleware integration <Badge type="warning" text="client" /><Badge type="danger" text="server" />
 
 Both the OpenIddict client and server ASP.NET Core hosts offer an option to render error pages using
 [ASP.NET Core's status code pages middleware](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/error-handling#usestatuscodepages).
@@ -226,7 +226,7 @@ services.AddOpenIddict()
 >  ```
 
 
-### Authorization and logout request caching (server-only)
+### Authorization and logout request caching <Badge type="danger" text="server" />
 
 To simplify flowing large authorization or logout requests, the OpenIddict server ASP.NET Core integration includes a built-in feature
 that allows generating a unique `request_id` and caching the received requests in an `IDistributedCache`: when this feature is enabled,
@@ -300,7 +300,7 @@ app.MapGet("challenge", () =>
 });
 ```
 
-### JSON responses indentation (server-only)
+### JSON responses indentation <Badge type="danger" text="server" />
 
 By default, the OpenIddict server ASP.NET Core host will return indented JSON responses to make them easier to read.