Blazor Web App with OIDC article

aspnetcore/blazor/hybrid/security/index.md

@@ -17,7 +17,7 @@ This article describes ASP.NET Core's support for the configuration and manageme
 
 ::: moniker range=">= aspnetcore-7.0"
 
-Authentication in Blazor Hybrid apps is handled by native platform libraries, as they offer enhanced security guarantees that the browser sandbox can't offer. Authentication of native apps uses an OS-specific mechanism or via a federated protocol, such as [OpenID Connect (OIDC)](https://openid.net/connect/). Follow the guidance for the identity provider that you've selected for the app and then further integrate identity with Blazor using the guidance in this article.
+Authentication in Blazor Hybrid apps is handled by native platform libraries, as they offer enhanced security guarantees that the browser sandbox can't offer. Authentication of native apps uses an OS-specific mechanism or via a federated protocol, such as [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/). Follow the guidance for the identity provider that you've selected for the app and then further integrate identity with Blazor using the guidance in this article.
 
 Integrating authentication must achieve the following goals for Razor components and services:
 
@@ -548,7 +548,7 @@ When implementing authentication:
 
 ::: moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
 
-Authentication in Blazor Hybrid apps is handled by native platform libraries, as they offer enhanced security guarantees that the browser sandbox can't offer. Authentication of native apps uses an OS-specific mechanism or via a federated protocol, such as [OpenID Connect (OIDC)](https://openid.net/connect/). Follow the guidance for the identity provider that you've selected for the app and then further integrate identity with Blazor using the guidance in this article.
+Authentication in Blazor Hybrid apps is handled by native platform libraries, as they offer enhanced security guarantees that the browser sandbox can't offer. Authentication of native apps uses an OS-specific mechanism or via a federated protocol, such as [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/). Follow the guidance for the identity provider that you've selected for the app and then further integrate identity with Blazor using the guidance in this article.
 
 Integrating authentication must achieve the following goals for Razor components and services:
 

aspnetcore/blazor/security/webassembly/index.md

@@ -12,7 +12,7 @@ uid: blazor/security/webassembly/index
 
 [!INCLUDE[](~/includes/not-latest-version.md)]
 
-Blazor WebAssembly apps are secured in the same manner as single-page applications (SPAs). There are several approaches for authenticating users to SPAs, but the most common and comprehensive approach is to use an implementation based on the [OAuth 2.0 protocol](https://oauth.net/), such as [OpenID Connect (OIDC)](https://openid.net/connect/).
+Blazor WebAssembly apps are secured in the same manner as single-page applications (SPAs). There are several approaches for authenticating users to SPAs, but the most common and comprehensive approach is to use an implementation based on the [OAuth 2.0 protocol](https://oauth.net/), such as [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/).
 
 The Blazor WebAssembly security documentation primarily focuses on how to accomplish user authentication and authorization tasks. For OAuth 2.0/OIDC general concept coverage, see the resources in the [main overview article's *Additional resources* section](xref:blazor/security/index#additional-resources).
 

aspnetcore/blazor/security/webassembly/standalone-with-authentication-library.md

@@ -30,7 +30,7 @@ The subsections of the walkthrough explain how to:
 
 ### Register an app
 
-Register an app with an [OpenID Connect (OIDC)](https://openid.net/connect/) Identity Provider (IP) following the guidance provided by the maintainer of the IP.
+Register an app with an [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) Identity Provider (IP) following the guidance provided by the maintainer of the IP.
 
 Record the following information:
 

aspnetcore/blazor/security/webassembly/standalone-with-identity.md

@@ -100,7 +100,7 @@ Access the sample apps through the latest version folder from the repository's r
 
 [View or download sample code](https://github.com/dotnet/blazor-samples) ([how to download](xref:index#how-to-download-a-sample))
 
-## Backend web API app
+## Backend web API app packages and code
 
 The backend web API app maintains a user identity store for ASP.NET Core Identity.
 
@@ -149,7 +149,7 @@ To secure an endpoint, add the <xref:Microsoft.AspNetCore.Builder.AuthorizationE
 For more information on basic patterns for initialization and configuration of a <xref:Microsoft.EntityFrameworkCore.DbContext> instance, see
 [DbContext Lifetime, Configuration, and Initialization](/ef/core/dbcontext-configuration/) in the EF Core documentation.
 
-## Frontend standalone Blazor WebAssembly app
+## Frontend standalone Blazor WebAssembly app packages and code
 
 A standalone Blazor WebAssembly frontend app demonstrates user authentication and authorization to access a private webpage.
 

aspnetcore/blazor/state-management.md

@@ -612,7 +612,7 @@ For permanent data persistence that spans multiple users and devices, the app ca
 
 After data is saved, the user's state is retained and available in any new browser session.
 
-Because Blazor WebAssembly apps run entirely in the user's browser, they require additional measures to access secure external systems, such as storage services and databases. Blazor WebAssembly apps are secured in the same manner as single-page applications (SPAs). Typically, an app authenticates a user via [OAuth](https://oauth.net)/[OpenID Connect (OIDC)](https://openid.net/connect/) and then interacts with storage services and databases through web API calls to a server-side app. The server-side app mediates the transfer of data between the Blazor WebAssembly app and the storage service or database. The Blazor WebAssembly app maintains an ephemeral connection to the server-side app, while the server-side app has a persistent connection to storage.
+Because Blazor WebAssembly apps run entirely in the user's browser, they require additional measures to access secure external systems, such as storage services and databases. Blazor WebAssembly apps are secured in the same manner as single-page applications (SPAs). Typically, an app authenticates a user via [OAuth](https://oauth.net)/[OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) and then interacts with storage services and databases through web API calls to a server-side app. The server-side app mediates the transfer of data between the Blazor WebAssembly app and the storage service or database. The Blazor WebAssembly app maintains an ephemeral connection to the server-side app, while the server-side app has a persistent connection to storage.
 
 For more information, see the following resources:
 

aspnetcore/fundamentals/minimal-apis/security.md

@@ -49,7 +49,7 @@ In some cases, such as controlling middleware order, it's necessary to explicitl
 Authentication strategies typically support a variety of configurations that are loaded via options. Minimal apps support loading options from configuration for the following authentication strategies:
 
 - [JWT bearer-based](https://jwt.io/introduction)
-- [OpenID Connection-based](https://openid.net/connect/)
+- [OpenID Connection-based](https://openid.net/developers/how-connect-works/)
 
 The ASP.NET Core framework expects to find these options under the `Authentication:Schemes:{SchemeName}` section in [configuration](/aspnet/core/fundamentals/configuration). In the following sample, two different schemes, `Bearer` and `LocalAuthIssuer`, are defined with their respective options. The `Authentication:DefaultScheme` option can be used to configure the default authentication strategy that's used.
 

aspnetcore/security/authentication/claims.md

@@ -17,7 +17,7 @@ By [Damien Bowden](https://github.com/damienbod)
 Claims can be created from any user or identity data which can be issued using a trusted identity provider or ASP.NET Core identity. A claim is a name value pair that represents what the subject is, not what the subject can do.
 This article covers the following areas:
 
-* How to configure and map claims using an [OpenID Connect](https://openid.net/connect/) client
+* How to configure and map claims using an [OpenID Connect](https://openid.net/developers/how-connect-works/) client
 * Set the name and role claim
 * Reset the claims namespaces
 * Customize, extend the claims using <xref:Microsoft.AspNetCore.Authentication.IClaimsTransformation.TransformAsync%2A>
@@ -100,7 +100,7 @@ Refer to the following document:
 Claims can be created from any user or identity data which can be issued using a trusted identity provider or ASP.NET Core identity. A claim is a name value pair that represents what the subject is, not what the subject can do.
 This article covers the following areas:
 
-* How to configure and map claims using an [OpenID Connect](https://openid.net/connect/) client
+* How to configure and map claims using an [OpenID Connect](https://openid.net/developers/how-connect-works/) client
 * Set the name and role claim
 * Reset the claims namespaces
 * Customize, extend the claims using <xref:Microsoft.AspNetCore.Authentication.IClaimsTransformation.TransformAsync%2A>

aspnetcore/security/authentication/index.md

@@ -96,7 +96,7 @@ Based on the authentication scheme's configuration and the incoming request cont
 
 ### `RemoteAuthenticationHandler<TOptions>` vs `AuthenticationHandler<TOptions>`
 
-<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/connect/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
+<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/developers/how-connect-works/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
 
 * Is the authentication provider.
 * Examples include [Facebook](xref:security/authentication/facebook-logins), [Twitter](xref:security/authentication/twitter-logins), [Google](xref:security/authentication/google-logins), [Microsoft](xref:security/authentication/microsoft-logins), and any other OIDC provider that handles authenticating users using the handlers mechanism.
@@ -245,7 +245,7 @@ Based on the authentication scheme's configuration and the incoming request cont
 
 ### `RemoteAuthenticationHandler<TOptions>` vs `AuthenticationHandler<TOptions>`
 
-<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/connect/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
+<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/developers/how-connect-works/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
 
 * Is the authentication provider.
 * Examples include [Facebook](xref:security/authentication/facebook-logins), [Twitter](xref:security/authentication/twitter-logins), [Google](xref:security/authentication/google-logins), [Microsoft](xref:security/authentication/microsoft-logins), and any other OIDC provider that handles authenticating users using the handlers mechanism.
@@ -388,7 +388,7 @@ Based on the authentication scheme's configuration and the incoming request cont
 
 ### `RemoteAuthenticationHandler<TOptions>` vs `AuthenticationHandler<TOptions>`
 
-<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/connect/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
+<xref:Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler%601> is the class for authentication that requires a remote authentication step. When the remote authentication step is finished, the handler calls back to the `CallbackPath` set by the handler. The handler finishes the authentication step using the information passed to the <xref:Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleRemoteAuthenticateAsync%2A> callback path. [OAuth 2.0](https://oauth.net/2/) and [OIDC](https://openid.net/developers/how-connect-works/) both use this pattern. JWT and cookies don't since they can directly use the bearer header and cookie to authenticate. The remotely hosted provider in this case:
 
 * Is the authentication provider.
 * Examples include [Facebook](xref:security/authentication/facebook-logins), [Twitter](xref:security/authentication/twitter-logins), [Google](xref:security/authentication/google-logins), [Microsoft](xref:security/authentication/microsoft-logins), and any other OIDC provider that handles authenticating users using the handlers mechanism.

aspnetcore/security/samesite.md

@@ -22,7 +22,7 @@ SameSite is an [IETF](https://ietf.org/about/) draft standard designed to provid
 * Applications that use [`<iframe>`](https://developer.mozilla.org/docs/Web/HTML/Element/iframe) may experience issues with `sameSite=Lax` or `sameSite=Strict` cookies because `<iframe>` is treated as cross-site scenarios.
 * The value `SameSite=None` is not allowed by the [2016 standard](https://tools.ietf.org/html/draft-west-first-party-cookies-07) and causes some implementations to treat such cookies as `SameSite=Strict`. See [Supporting older browsers](#sob) in this document.
 
-The `SameSite=Lax` setting works for most application cookies. Some forms of authentication like [OpenID Connect](https://openid.net/connect/) (OIDC) and [WS-Federation](https://auth0.com/docs/protocols/ws-fed) default to POST based redirects. The POST based redirects trigger the SameSite browser protections, so SameSite is disabled for these components. Most [OAuth](https://oauth.net/) logins are not affected due to differences in how the request flows.
+The `SameSite=Lax` setting works for most application cookies. Some forms of authentication like [OpenID Connect](https://openid.net/developers/how-connect-works/) (OIDC) and [WS-Federation](https://auth0.com/docs/protocols/ws-fed) default to POST based redirects. The POST based redirects trigger the SameSite browser protections, so SameSite is disabled for these components. Most [OAuth](https://oauth.net/) logins are not affected due to differences in how the request flows.
 
 Each ASP.NET Core component that emits cookies needs to decide if SameSite is appropriate.
 

aspnetcore/toc.yml

@@ -578,6 +578,8 @@ items:
                     uid: blazor/security/server/static-server-side-rendering
                   - name: Interactive server-side rendering threats
                     uid: blazor/security/server/interactive-server-side-rendering
+                  - name: Blazor Web App with OIDC
+                    uid: blazor/security/server/blazor-web-app-oidc
                   - name: Account confirmation and password recovery
                     uid: blazor/security/server/account-confirmation-and-password-recovery
                   - name: Additional scenarios

aspnetcore/zone-pivot-groups.yml

@@ -80,3 +80,11 @@ groups:
       title: Graph SDK v4
     - id: graph-sdk-5
       title: Graph SDK v5
+- id: blazor-web-app-oidc-specification
+  title: Specification
+  prompt: Choose the app specification
+  pivots:
+    - id: blazor-web-app
+      title: Blazor Web App
+    - id: blazor-web-app-bff
+      title: Blazor Web App (BFF pattern)