Update the documentation to clarify mobile platforms are supported by the OpenIddict Web providers

guides/getting-started/index.md

@@ -8,9 +8,9 @@ OpenIddict features three independent stacks:
   - A **validation stack**, that allows implementing token authentication support for your ASP.NET 4.6.1+ and ASP.NET Core 2.1+ APIs.
    To get started, read [Implementing token validation in your APIs](implementing-token-validation-in-your-apis.md).
 
-  - A **client stack**, that allows integrating with internal or external OAuth 2.0/OpenID Connect servers. The client stack can be used in
-  ASP.NET 4.6.1+ or ASP.NET Core 2.1+ applications and can also be used in non-web applications (e.g Windows/Linux console applications
-  or Windows desktop applications).  To get started, read
+  - A **client stack**, that allows integrating with internal or external OAuth 2.0/OpenID Connect servers.
+  The client stack can be used in ASP.NET 4.6.1+ or ASP.NET Core 2.1+ applications and can also be used
+  in non-web applications (e.g Android, iOS, Linux, macOS and Windows applications). To get started, read
   [Integrating with a remote server instance](integrating-with-a-remote-server-instance.md).
 
 > [!NOTE]

integrations/web-providers.md

@@ -134,7 +134,7 @@ While the OpenIddict Web providers share some similarities with the
    URIs of a provider when possible, making the OpenIddict Web providers more robust and more future-proof.
 
  - While the aspnet-contrib providers require targeting the latest ASP.NET Core version, **the OpenIddict Web providers can be
-   used in any supported version**. They can also be used in ASP.NET 4.6.1+ websites and Windows/Linux desktop applications.
+   used in any supported version**. They can also be used in ASP.NET 4.6.1+ websites and mobile/desktop applications.
 
  - **OpenIddict uses `Microsoft.Extensions.Http.Polly` (or `Microsoft.Extensions.Http.Resilience` on .NET 8+)
    to make backchannel HTTP communications less prone to transient network errors**.
@@ -333,8 +333,8 @@ public async Task<ActionResult> LogInWithGitHubInstanceA(string returnUrl)
 
 ### Configure a different display name that will be visible by the users
 
-When using in an ASP.NET Core application using ASP.NET Core Identity and its default UI, the login page automatically
-lists the external providers configured in the application, including the OpenIddict Web providers.
+When using ASP.NET Core Identity and its default UI, the login page automatically lists the
+external providers configured in the application, including the OpenIddict Web providers.
 
 While OpenIddict automatically assigns a default display name, that value can be overridden using the `SetProviderDisplayName()` API:
 

introduction.md

@@ -70,19 +70,16 @@ Unlike other solutions, **OpenIddict exclusively focuses on the OAuth 2.0/OpenID
 and leaves user authentication up to the implementer: OpenIddict can be natively used with any form of user authentication like password, token,
 federated or Integrated Windows Authentication (NTLM/Kerberos). While convenient, using a membership stack like ASP.NET Core Identity is not required.
 
-> [!TIP]
-> When used with ASP.NET or ASP.NET Core, integration with OpenIddict is typically done by enabling the pass-through mode to handle requests in a
-> controller action, in a Razor Page, in a Web Form or in a minimal API handler or, for more complex scenarios, by directly using its advanced events model.
-
 ### Pass-through support
 
-As with `OAuthAuthorizationServerMiddleware`, the OpenIddict server allows handling authorization, logout and token requests in custom controller actions or
+Similarly to `OAuthAuthorizationServerMiddleware`, the OpenIddict server allows handling authorization, logout and token requests in custom controller actions or
 any other middleware able to hook into the ASP.NET Core or OWIN request processing pipeline. In this case, OpenIddict will always validate incoming requests
 first (e.g by ensuring the mandatory parameters are present and valid) before allowing the rest of the pipeline to be invoked: should any validation error occur,
 OpenIddict will automatically reject the request before it reaches user-defined controller actions or custom middleware.
 
 The same exact concept also exists in the OpenIddict client stack, where the pass-through mode can be used to handle callbacks/redirection requests in
-custom code and apply any logic needed by the application (e.g filtering claims, storing the identity in an authentication cookie, etc.). 
+custom code (for instance, a controller action, a Razor Page, a Web Form or a minimal API handler) and apply any logic needed by the application
+(e.g filtering claims, storing the identity in an authentication cookie, etc.). 
 
 ```csharp
 builder.Services.AddOpenIddict()