Sécuriser une application web ASP.NET Core Blazor avec OpenID Connect (OIDC)

Article
03/14/2024

Cet article explique comment sécuriser une application web Blazor avec OpenID Connect (OIDC) en utilisant un exemple d’application dans le référentiel GitHub dotnet/blazor-samples (.NET 8 ou version ultérieure) (comment télécharger).

Cette version de l’article traite de l’implémentation d’OIDC sans adopter le Modèle BFF (Backend for Frontend). Le modèle BFF est pratique pour faire des requêtes authentifiées auprès de services externes. Changez le sélecteur de version de l’article en OIDC avec le modèle BFF si la spécification de l’application appelle à adopter le modèle BFF.

La spécification suivante est couverte :

L’application web Blazor utilise le mode de rendu automatique avec interactivité globale.
Les services de fournisseur d’état d’authentification personnalisée sont utilisés par les applications serveur et clientes pour capturer l’état d’authentification de l’utilisateur et le transmettre entre le serveur et le client.
Cette application est un point de départ pour les flux d’authentification OIDC. OIDC est configuré manuellement dans l’application et ne s’appuie pas sur des packages Microsoft Entra ID ou Microsoft Identity Web, et l’exemple d’application ne nécessite pas d’hébergement Microsoft Azure. L’exemple d’application peut cependant être utilisé avec Entra ou Microsoft Identity Web, et être hébergé dans Azure.
Actualisation automatique des jetons non interactifs.
Appelle de façon sécurisée une API (web) dans le projet de serveur pour les données.

Exemple d’application

Cet exemple d’application est composé de deux projets :

BlazorWebAppOidc : projet côté serveur de l’application web Blazor, contenant un exemple de point de terminaison d’API minimale pour des données météorologiques.
BlazorWebAppOidc.Client : projet côté client de l’application web Blazor.

Accédez aux exemples d’applications par le biais du dossier de version le plus récent à partir de la racine du référentiel avec le lien suivant. Les projets se trouvent dans le dossier BlazorWebAppOidc pour .NET 8 ou ultérieur.

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Projet d’application web Blazor côté serveur (`BlazorWebAppOidc`)

Le projet BlazorWebAppOidc est le projet côté serveur de l’application web Blazor.

Le fichier BlazorWebAppOidc.http peut être utilisé pour tester la requête de données météorologiques. Notez que le projet BlazorWebAppOidc doit être en cours d’exécution pour tester le point de terminaison et que le point de terminaison est codé en dur dans le fichier. Pour en savoir plus, reportez-vous à Utiliser des fichiers .http dans Visual Studio 2022.

Remarque

Le projet de serveur utilise IHttpContextAccessor/HttpContext, mais jamais pour les composants affichés de manière interactive. Pour plus d’informations, consultez Guide d’atténuation des menaces pour l’affichage interactif côté serveur de Blazor ASP.NET Core.

Configuration

Cette section explique comment configurer l’exemple d’application.

Remarque

Pour Microsoft Entra ID et Azure AD B2C, vous pouvez utiliser AddMicrosoftIdentityWebApp de Microsoft Identity Web (package NuGet Microsoft.Identity.Web, documentation de l’API ), qui ajoute les gestionnaires d’authentification OIDC et Cookie avec les valeurs par défaut appropriées. L’exemple d’application et l’aide de cette section n’utilisent pas Microsoft Identity Web. L’aide montre comment configurer manuellement le gestionnaire OIDC pour n’importe quel fournisseur OIDC. Pour plus d’informations sur l’implémentation de Microsoft Identity Web, consultez les ressources liées.

La configuration OpenIdConnectOptions suivante se trouve dans le fichier Program du projet sur l’appel à AddOpenIdConnect :

SignInScheme : définit le schéma d’authentification correspondant à l’intergiciel responsable de la conservation de l’identité de l’utilisateur après une authentification réussie. Le gestionnaire OIDC doit utiliser un schéma de connexion capable de conserver les informations d’identification de l’utilisateur entre les requêtes. La ligne suivante est présente seulement à des fins de démonstration. Si elle est omise, DefaultSignInScheme est utilisé comme valeur de secours.
```
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
```
Étendues pour openid et profile (Scope) (Facultatif) : les étendues openid et profile sont également configurées par défaut, car elles sont nécessaires pour que le gestionnaire OIDC fonctionne, mais il peut être nécessaire de les ajouter à nouveau si des étendues sont incluses dans la configuration de Authentication:Schemes:MicrosoftOidc:Scope. Pour obtenir une aide générale sur la configuration, consultez Configuration dans ASP.NET Core et Configuration d’ASP.NET Core Blazor.
```
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
```
SaveTokens : définit si les jetons d’accès et d’actualisation doivent être stockés dans les AuthenticationProperties après une autorisation réussie. Cette propriété est définie par défaut sur false pour réduire la taille du cookie d’authentification finale.
```
oidcOptions.SaveTokens = false;
```
Étendue de l’accès hors connexion (Scope) : l’étendue offline_access est nécessaire pour le jeton d’actualisation.
```
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
```
Authority et ClientId : définit l’autorité et l’ID client pour les appels OIDC.
```
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
```
Exemple :
- Autorité ({AUTHORITY}) : https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ (utilise l’ID de locataire a3942615-d115-4eb7-bc84-9974abcf5064)
- ID client ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
```
oidcOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";
oidcOptions.ClientId = "4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";
```
Exemple pour l’autorité « common » de Microsoft Azure :

L’autorité « common » doit être utilisée pour les applications multilocataires. Vous pouvez également utiliser l’autorité « common » pour les applications monolocataires, mais un IssuerValidator personnalisé est nécessaire, comme indiqué plus loin dans cette section.
```
oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
```
ClientSecret : la clé secrète client d’OIDC.

L’exemple suivant est destiné seulement à des fins de test et de démonstration. Ne stockez pas la clé secrète client dans l’assembly de l’application et n’archivez pas le secret dans le contrôle de code source. Stockez la clé secrète client dans Secrets utilisateur, dans Azure Key Vault ou dans une variable d’environnement.

La configuration du schéma d’authentification est lue automatiquement dans builder.Configuration["Authentication:Schemes:{SCHEME NAME}:{PropertyName}"], où l’espace réservé {SCHEME NAME} est le schéma, qui est MicrosoftOidc par défaut. Comme la configuration est préconfigurée, une clé secrète client peut être lue automatiquement via la clé de configuration Authentication:Schemes:MicrosoftOidc:ClientSecret. Sur le serveur, en utilisant des variables d’environnement, nommez la variable d’environnement Authentication__Schemes__MicrosoftOidc__ClientSecret :
```
set Authentication__Schemes__MicrosoftOidc__ClientSecret={CLIENT SECRET}
```
À des fins de démonstration et de test uniquement, vous pouvez définir le ClientSecret directement. Ne définissez pas la valeur directement pour les applications de production déployées. Pour une sécurité légèrement améliorée, compilez conditionnellement la ligne avec le symbole DEBUG :
```
#if DEBUG
oidcOptions.ClientSecret = "{CLIENT SECRET}";
#endif
```
Exemple :

Clé secrète client ({CLIENT SECRET}) : 463471c8c4...f90d674bc9 (raccourcie pour l’affichage)
```
#if DEBUG
oidcOptions.ClientSecret = "463471c8c4...137f90d674bc9";
#endif
```
ResponseType : configure le gestionnaire OIDC pour effectuer seulement le flux du code d’autorisation. Les octrois implicites et les flux hybrides ne sont pas nécessaires dans ce mode.

Dans la configuration de l’inscription d’application Octroi implicite et flux hybrides du portail Entra ou Azure, ne cochez *pas la case pour que le point de terminaison d’autorisation retourne des jetons d’accès ou des jetons d’ID. Le gestionnaire OIDC demande automatiquement les jetons appropriés en utilisant le code retourné par le point de terminaison d’autorisation.
```
oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
```
MapInboundClaims et configuration de NameClaimType et de RoleClaimType : de nombreux serveurs OIDC utilisent « name » et « role » au lieu des valeurs par défaut de SOAP/WS-Fed dans ClaimTypes. Quand MapInboundClaims est défini sur false, le gestionnaire n’effectue pas de mappages de revendications et les noms de revendication du JWT sont utilisés directement par l’application. L’exemple suivant mappe manuellement les revendications de nom et de rôle :

Remarque

MapInboundClaims doit être défini sur false pour la plupart des fournisseurs OIDC, ce qui empêche le renommage des revendications.

oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = JwtRegisteredClaimNames.Name;
oidcOptions.TokenValidationParameters.RoleClaimType = "role";

Configuration du chemin d’accès : les chemins d’accès doivent correspondre à l’URI de redirection (chemin d’accès du rappel de la connexion) et publier les chemins d’accès de redirection de déconnexion (chemin d’accès du rappel déconnecté) configurés lors de l’inscription de l’application auprès du fournisseur OIDC. Dans le portail Azure, les chemins d’accès sont configurés dans le panneau Authentification de l’inscription de l’application. Les chemins d’accès de connexion et de déconnexion doivent être enregistrés en tant qu’URI de redirection. Les valeurs par défaut sont /signin-oidc et /signout-callback-oidc.
- CallbackPath : le chemin d’accès de la demande dans le chemin d’accès de base de l’application où l’agent utilisateur est retourné.
  
  Dans le portail Entra ou Azure, définissez le chemin d’accès dans l’URI de redirection de la configuration de la plateforme web :
  
  https://localhost/signin-oidc
  
  Remarque
  
  Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs OIDC nécessitent un port correct.
- SignedOutCallbackPath : le chemin d’accès de requête dans le chemin d’accès de base de l’application où l’agent utilisateur est retourné après la déconnexion du fournisseur d’identité.
  
  Dans le portail Entra ou Azure, définissez le chemin d’accès dans l’URI de redirection de la configuration de la plateforme web :
  
  https://localhost/signout-callback-oidc
  
  Remarque
  
  Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs OIDC nécessitent un port correct.
  
  Remarque
  
  Si vous utilisez Microsoft Identity Web, le fournisseur redirige actuellement seulement vers SignedOutCallbackPath si l’autorité microsoftonline.com (https://login.microsoftonline.com/{TENANT ID}/v2.0/) est utilisée. Cette limitation n’existe pas si vous pouvez utiliser l’autorité « common » avec Microsoft Identity Web. Pour plus d’informations, consultez postLogoutRedirectUri ne fonctionne pas quand l’URL de l’autorité contient un ID de locataire (AzureAD/microsoft-authentication-library-for-js #5783).
- RemoteSignOutPath : les demandes reçues sur ce chemin d’accès font que le gestionnaire appelle la déconnexion en utilisant le schéma de déconnexion.
  
  Dans le portail Entra ou Azure, définissez l’URL de déconnexion du canal frontal :
  
  https://localhost/signout-oidc
  
  Remarque
  
  Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs OIDC nécessitent un port correct.
```
oidcOptions.CallbackPath = new PathString("{PATH}");
oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
```
Exemples (valeurs par défaut) :
```
oidcOptions.CallbackPath = new PathString("/signin-oidc");
oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
```
(Microsoft Azure uniquement avec le point de terminaison « common ») TokenValidationParameters.IssuerValidator : de nombreux fournisseurs OIDC fonctionnent avec le validateur émetteur par défaut, mais nous devons tenir compte de l’émetteur paramétré avec l’ID de locataire ({TENANT ID}) retourné par https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Pour plus d’informations, consultez SecurityTokenInvalidIssuerException avec OpenID Connect et le point de terminaison « common » d’Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

Uniquement pour les applications utilisant Microsoft Entra ID ou Azure AD B2C avec le point de terminaison « common » :
```
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
```

Exemple de code d’application

Examinez les fonctionnalités suivantes dans l’exemple d’application :

Actualisation automatique des jetons non interactifs avec l’aide d’un actualiseur cookie personnalisé (CookieOidcRefresher.cs).
La classe PersistingAuthenticationStateProvider (PersistingAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté serveur qui utilise PersistentComponentState pour transmettre l’état de l’authentification au client, qui est ensuite fixé pour la durée de vie de l’application WebAssembly.
Un exemple de requête adressée à l’application web Blazor pour des données météorologiques est géré par un point de terminaison d’API minimale (/weather-forecast) dans le fichier Program (Program.cs). Le point de terminaison demande une autorisation en appelant RequireAuthorization. Pour les contrôleurs que vous ajoutez au projet, ajoutez l’attribut [Authorize] au contrôleur ou à l’action.
L’application appelle de façon sécurisée une API (web) dans le projet de serveur pour les données météo :
- Lors du rendu du composant Weather sur le serveur, le composant utilise le ServerWeatherForecaster sur le serveur pour obtenir les données météo directement (et non via un appel d’API web).
- Lorsque le composant est rendu sur le client, le composant utilise l’implémentation du service ClientWeatherForecaster, qui utilise un HttpClient préconfiguré (dans le fichier Program du projet client) pour effectuer un appel d’API web au projet de serveur. Un point de terminaison d’API minimal (/weather-forecast) défini dans le fichier Program du projet de serveur obtient les données météo du ServerWeatherForecaster et retourne les données au client.

Pour plus d’informations sur les appels d’API (web) à l’aide d’abstractions de service dans les applications web Blazor, consultez Appeler une API web à partir d’une application ASP.NET CoreBlazor.

Projet d’application web Blazor côté client (`BlazorWebAppOidc.Client`)

Le projet BlazorWebAppOidc.Client est le projet côté client de l’application web Blazor.

La classe PersistentAuthenticationStateProvider (PersistentAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté client qui détermine l’état d’authentification de l’utilisateur en recherchant les données conservées dans la page quand elle a été rendue sur le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.

Si l’utilisateur doit se connecter ou se déconnecter, un rechargement complet de la page est nécessaire.

L’exemple d’application fournit un nom d’utilisateur et un e-mail seulement à des fins d’affichage. Il n’inclut pas de jetons qui s’authentifient auprès du serveur lors de requêtes ultérieures, celles-ci étant gérées séparément en utilisant un cookie qui est inclus dans les requêtes HttpClient envoyées au serveur.

Cette version de l’article traite de l’implémentation d’OIDC avec le modèle BFF (Backend for Frontend). Changez le sélecteur de version de l’article en OIDC sans le modèle BFF si la spécification de l’application n’appelle pas à adopter le modèle BFF.

La spécification suivante est couverte :

L’application web Blazor utilise le mode de rendu automatique avec interactivité globale.
Les services de fournisseur d’état d’authentification personnalisée sont utilisés par les applications serveur et clientes pour capturer l’état d’authentification de l’utilisateur et le transmettre entre le serveur et le client.
Cette application est un point de départ pour les flux d’authentification OIDC. OIDC est configuré manuellement dans l’application et ne s’appuie pas sur des packages Microsoft Entra ID ou Microsoft Identity Web, et l’exemple d’application ne nécessite pas d’hébergement Microsoft Azure. L’exemple d’application peut cependant être utilisé avec Entra ou Microsoft Identity Web, et être hébergé dans Azure.
Actualisation automatique des jetons non interactifs.
Le modèle BFF (Backend for Frontend) est adopté en utilisant .NET Aspire pour la découverte de services et YARP pour proxyser les requêtes vers un point de terminaison de prévision météorologique sur l’application back-end.
- Une API web back-end utilise l’authentification du porteur JWT pour valider les jetons JWT enregistrés par l’application web Blazor dans le cookie de la connexion.
- Aspire améliore l’expérience de création d’applications natives Cloud .NET. Il fournit un ensemble cohérent et validé d’outils et de modèles pour la création et l’exécution d’applications distribuées.
- YARP (Yet Another Reverse Proxy) est une bibliothèque utilisée pour créer un serveur proxy inverse.

Avertissement quant au package en préversion

Avertissement

Les technologies et les packages utilisés par l’exemple d’application BlazorWebAppOidcBff et décrits dans cet article sont actuellement en préversion. Le contenu de l’article, l’API et l’exemple d’application ne sont pas pris en charge pour l’instant, et ils ne sont actuellement pas recommandés pour une utilisation en production. L’exemple d’application et l’aide sont susceptibles de modification sans préavis.

Prérequis

.NET Aspire nécessite Visual Studio version 17.10 ou ultérieure.

Exemple d’application

L’exemple d’application est composé de cinq projets :

.NET Aspire :
- Aspire.AppHost : utilisé pour gérer les problèmes d’orchestration généraux de l’application.
- Aspire.ServiceDefaults : contient les configurations d’application Aspire .NET par défaut, qui peuvent être étendues et personnalisées en fonction des besoins.
MinimalApiJwt : API web back-end, contenant un exemple de point de terminaison d’API minimale pour les données météorologiques.
BlazorWebAppOidc : projet côté serveur de l’application web Blazor.
BlazorWebAppOidc.Client : projet côté client de l’application web Blazor.

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Projets .NET Aspire

Pour plus d’informations sur l’utilisation de .NET Aspire et des détails sur les projets .AppHost et .ServiceDefaults de l’exemple d’application, consultez la documentation .NET Aspire.

Vérifiez que vous avez satisfait aux prérequis pour .NET Aspire. Pour plus d’informations, consultez la section Prérequis de Démarrage rapide : Créer votre première application .NET Aspire.

Projet d’application web Blazor côté serveur (`BlazorWebAppOidc`)

Le projet BlazorWebAppOidc est le projet côté serveur de l’application web Blazor. Le projet utilise YARP pour proxyser les requêtes vers un point de terminaison de prévision météorologique dans le projet d’API web back-end (MinimalApiJwt) avec le access_token stocké dans le cookie d’authentification.

Remarque

Configuration

Cette section explique comment configurer l’exemple d’application.

Remarque

La configuration OpenIdConnectOptions suivante se trouve dans le fichier Program du projet sur l’appel à AddOpenIdConnect :

SignInScheme : définit le schéma d’authentification correspondant à l’intergiciel responsable de la conservation de l’identité de l’utilisateur après une authentification réussie. Le gestionnaire OIDC doit utiliser un schéma de connexion capable de conserver les informations d’identification de l’utilisateur entre les requêtes. La ligne suivante est présente seulement à des fins de démonstration. Si elle est omise, DefaultSignInScheme est utilisé comme valeur de secours.
```
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
```
Étendues pour openid et profile (Scope) (Facultatif) : les étendues openid et profile sont également configurées par défaut, car elles sont nécessaires pour que le gestionnaire OIDC fonctionne, mais il peut être nécessaire de les ajouter à nouveau si des étendues sont incluses dans la configuration de Authentication:Schemes:MicrosoftOidc:Scope. Pour obtenir une aide générale sur la configuration, consultez Configuration dans ASP.NET Core et Configuration d’ASP.NET Core Blazor.
```
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
```
SaveTokens : définit si les jetons d’accès et d’actualisation doivent être stockés dans les AuthenticationProperties après une autorisation réussie. La valeur est définie sur true pour authentifier les requêtes de données météorologiques depuis le projet d’API web back-end (MinimalApiJwt).
```
oidcOptions.SaveTokens = true;
```
Étendue de l’accès hors connexion (Scope) : l’étendue offline_access est nécessaire pour le jeton d’actualisation.
```
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
```
Étendues pour obtenir des données météorologiques depuis l’API web (Scope) : l’étendue Weather.Get est configurée dans le portail Azure ou Entra sous Exposer une API. Ceci est nécessaire pour que le projet d’API web back-end (MinimalApiJwt) valide le jeton d’accès avec le porteur JWT.
```
oidcOptions.Scope.Add("{APP ID URI}/{API NAME}");
```
Exemple :
- URI ID D’application : ({APP ID URI}) : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
  - Nom du répertoire : ({DIRECTORY NAME}) : contoso
  - ID d’application (client) ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
- Étendue configurée pour les données météorologiques provenant de MinimalApiJwt : ({API NAME}) : Weather.Get
```
oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f/Weather.Get");
```
L’exemple précédent concerne une application inscrite dans un locataire avec un type de locataire AAD B2C. Si l’application est inscrite dans un locataire ME-ID, l’URI d’ID d’application est différent et l’étendue est donc différente.

Exemple :
- URI d’ID d’application ({APP ID URI}) : api://{CLIENT ID} avec l’ID d’application (client) ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
- Étendue configurée pour les données météorologiques provenant de MinimalApiJwt : ({API NAME}) : Weather.Get
```
oidcOptions.Scope.Add("api://4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f/Weather.Get");
```
Authority et ClientId : définit l’autorité et l’ID client pour les appels OIDC.
```
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
```
Exemple :
- Autorité ({AUTHORITY}) : https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ (utilise l’ID de locataire a3942615-d115-4eb7-bc84-9974abcf5064)
- ID client ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
```
oidcOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";
oidcOptions.ClientId = "4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";
```
Exemple pour l’autorité « common » de Microsoft Azure :

L’autorité « common » doit être utilisée pour les applications multilocataires. Vous pouvez également utiliser l’autorité « common » pour les applications monolocataires, mais un IssuerValidator personnalisé est nécessaire, comme indiqué plus loin dans cette section.
```
oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
```
ClientSecret : la clé secrète client d’OIDC.

L’exemple suivant est destiné seulement à des fins de test et de démonstration. Ne stockez pas la clé secrète client dans l’assembly de l’application et n’archivez pas le secret dans le contrôle de code source. Stockez la clé secrète client dans Secrets utilisateur, dans Azure Key Vault ou dans une variable d’environnement.

La configuration du schéma d’authentification est lue automatiquement dans builder.Configuration["Authentication:Schemes:{SCHEME NAME}:{PropertyName}"], où l’espace réservé {SCHEME NAME} est le schéma, qui est MicrosoftOidc par défaut. Comme la configuration est préconfigurée, une clé secrète client peut être lue automatiquement via la clé de configuration Authentication:Schemes:MicrosoftOidc:ClientSecret. Sur le serveur, en utilisant des variables d’environnement, nommez la variable d’environnement Authentication__Schemes__MicrosoftOidc__ClientSecret :
```
set Authentication__Schemes__MicrosoftOidc__ClientSecret={CLIENT SECRET}
```
À des fins de démonstration et de test uniquement, vous pouvez définir le ClientSecret directement. Ne définissez pas la valeur directement pour les applications de production déployées. Pour une sécurité légèrement améliorée, compilez conditionnellement la ligne avec le symbole DEBUG :
```
#if DEBUG
oidcOptions.ClientSecret = "{CLIENT SECRET}";
#endif
```
Exemple :

Clé secrète client ({CLIENT SECRET}) : 463471c8c4...f90d674bc9 (raccourcie pour l’affichage)
```
#if DEBUG
oidcOptions.ClientSecret = "463471c8c4...137f90d674bc9";
#endif
```
ResponseType : configure le gestionnaire OIDC pour effectuer seulement le flux du code d’autorisation. Les octrois implicites et les flux hybrides ne sont pas nécessaires dans ce mode.

Dans la configuration de l’inscription d’application Octroi implicite et flux hybrides du portail Entra ou Azure, ne cochez *pas la case pour que le point de terminaison d’autorisation retourne des jetons d’accès ou des jetons d’ID. Le gestionnaire OIDC demande automatiquement les jetons appropriés en utilisant le code retourné par le point de terminaison d’autorisation.
```
oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
```
MapInboundClaims et configuration de NameClaimType et de RoleClaimType : de nombreux serveurs OIDC utilisent « name » et « role » au lieu des valeurs par défaut de SOAP/WS-Fed dans ClaimTypes. Quand MapInboundClaims est défini sur false, le gestionnaire n’effectue pas de mappages de revendications et les noms de revendication du JWT sont utilisés directement par l’application. L’exemple suivant mappe manuellement les revendications de nom et de rôle :

Remarque

MapInboundClaims doit être défini sur false pour la plupart des fournisseurs OIDC, ce qui empêche le renommage des revendications.

oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = JwtRegisteredClaimNames.Name;
oidcOptions.TokenValidationParameters.RoleClaimType = "role";

Configuration du chemin d’accès : les chemins d’accès doivent correspondre à l’URI de redirection (chemin d’accès du rappel de la connexion) et publier les chemins d’accès de redirection de déconnexion (chemin d’accès du rappel déconnecté) configurés lors de l’inscription de l’application auprès du fournisseur OIDC. Dans le portail Azure, les chemins d’accès sont configurés dans le panneau Authentification de l’inscription de l’application. Les chemins d’accès de connexion et de déconnexion doivent être enregistrés en tant qu’URI de redirection. Les valeurs par défaut sont /signin-oidc et /signout-callback-oidc.
- CallbackPath : le chemin d’accès de la demande dans le chemin d’accès de base de l’application où l’agent utilisateur est retourné.
  
  Dans le portail Entra ou Azure, définissez le chemin d’accès dans l’URI de redirection de la configuration de la plateforme web :
  
  https://localhost/signin-oidc
  
  Remarque
  
  Un port n’est pas nécessaire pour les adresses localhost.
- SignedOutCallbackPath : le chemin d’accès de requête dans le chemin d’accès de base de l’application où l’agent utilisateur est retourné après la déconnexion du fournisseur d’identité.
  
  Dans le portail Entra ou Azure, définissez le chemin d’accès dans l’URI de redirection de la configuration de la plateforme web :
  
  https://localhost/signout-callback-oidc
  
  Remarque
  
  Un port n’est pas nécessaire pour les adresses localhost.
  
  Remarque
  
  Si vous utilisez Microsoft Identity Web, le fournisseur redirige actuellement seulement vers SignedOutCallbackPath si l’autorité microsoftonline.com (https://login.microsoftonline.com/{TENANT ID}/v2.0/) est utilisée. Cette limitation n’existe pas si vous pouvez utiliser l’autorité « common » avec Microsoft Identity Web. Pour plus d’informations, consultez postLogoutRedirectUri ne fonctionne pas quand l’URL de l’autorité contient un ID de locataire (AzureAD/microsoft-authentication-library-for-js #5783).
- RemoteSignOutPath : les demandes reçues sur ce chemin d’accès font que le gestionnaire appelle la déconnexion en utilisant le schéma de déconnexion.
  
  Dans le portail Entra ou Azure, définissez l’URL de déconnexion du canal frontal :
  
  https://localhost/signout-oidc
  
  Remarque
  
  Un port n’est pas nécessaire pour les adresses localhost.
```
oidcOptions.CallbackPath = new PathString("{PATH}");
oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
```
Exemples (valeurs par défaut) :
```
oidcOptions.CallbackPath = new PathString("/signin-oidc");
oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
```
(Microsoft Azure uniquement avec le point de terminaison « common ») TokenValidationParameters.IssuerValidator : de nombreux fournisseurs OIDC fonctionnent avec le validateur émetteur par défaut, mais nous devons tenir compte de l’émetteur paramétré avec l’ID de locataire ({TENANT ID}) retourné par https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Pour plus d’informations, consultez SecurityTokenInvalidIssuerException avec OpenID Connect et le point de terminaison « common » d’Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

Uniquement pour les applications utilisant Microsoft Entra ID ou Azure AD B2C avec le point de terminaison « common » :
```
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
```

Exemple de code d’application

Examinez les fonctionnalités suivantes dans l’exemple d’application :

Actualisation automatique des jetons non interactifs avec l’aide d’un actualiseur cookie personnalisé (CookieOidcRefresher.cs).
La classe PersistingAuthenticationStateProvider (PersistingAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté serveur qui utilise PersistentComponentState pour transmettre l’état de l’authentification au client, qui est ensuite fixé pour la durée de vie de l’application WebAssembly.
Les requêtes adressées à l’application web Blazor sont proxysées vers le projet d’API web back-end (MinimalApiJwt). MapForwarder dans le fichier Program ajoute le transfert direct des requêtes HTTP qui correspondent au modèle spécifié à une destination spécifique en utilisant la configuration par défaut pour la requête sortante, des transformations personnalisées et le client HTTP par défaut :
- Lors du rendu du composant Weather sur le serveur, le composant utilise le ServerWeatherForecaster pour proxyser la demande de données météo avec le jeton d’accès de l’utilisateur.
- Lorsque le composant est rendu sur le client, le composant utilise l’implémentation du service ClientWeatherForecaster, qui utilise un HttpClient préconfiguré (dans le fichier Program du projet client) pour effectuer un appel d’API web au projet de serveur. Un point de terminaison d’API minimal (/weather-forecast) défini dans le fichier Program du projet de serveur transforme la requête avec le jeton d’accès de l’utilisateur pour obtenir les données météo.

Projet d’application web Blazor côté client (`BlazorWebAppOidc.Client`)

Le projet BlazorWebAppOidc.Client est le projet côté client de l’application web Blazor.

Si l’utilisateur doit se connecter ou se déconnecter, un rechargement complet de la page est nécessaire.

Projet d’API web back-end (`MinimalApiJwt`)

Le projet MinimalApiJwt est une API web back-end pour plusieurs projets front-end. Le projet configure un point de terminaison d’API minimale pour les données météorologiques. Les requêtes provenant du projet côté serveur d’application web Blazor (BlazorWebAppOidc) sont proxysées vers le projet MinimalApiJwt.

Configuration

Configurez le projet dans les JwtBearerOptions de l’appel AddJwtBearer dans le fichier Program du projet :

Audience : définit l’audience pour les jetons OpenID Connect reçus.

Dans le portail Azure ou Entra : faites correspondre la valeur au chemin d’accès de l’URI d’ID d’application configuré lors de l’ajout de l’étendue Weather.Get sous Exposer une API :
```
jwtOptions.Audience = "{APP ID URI}";
```
Exemple :

URI ID d’application : ({APP ID URI}) : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
- Nom du répertoire : ({DIRECTORY NAME}) : contoso
- ID d’application (client) ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
```
jwtOptions.Audience = "https://contoso.onmicrosoft.com/4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";
```
L’exemple précédent concerne une application inscrite dans un locataire avec un type de locataire AAD B2C. Si l’application est inscrite dans un locataire ME-ID, l’URI d’ID d’application est différent et l’étendue est donc différente.

Exemple :

URI d’ID d’application ({APP ID URI}) : api://{CLIENT ID} avec l’ID d’application (client) ({CLIENT ID}) : 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
```
jwtOptions.Audience = "api://4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";
```
Authority : définit l’autorité pour effectuer des appels OpenID Connect. Faire correspondre la valeur à l’autorité configurée pour le gestionnaire OIDC dans BlazorWebAppOidc/Program.cs :
```
jwtOptions.Authority = "{AUTHORITY}";
```
Exemple :

Autorité ({AUTHORITY}) : https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ (utilise l’ID de locataire a3942615-d115-4eb7-bc84-9974abcf5064)
```
jwtOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";
```
L’exemple précédent concerne une application inscrite dans un locataire avec un type de locataire AAD B2C. Si l’application est inscrite dans un locataire ME-ID, l’autorité doit correspondre à l’émetteur (iss) du jeton JWT retourné par le fournisseur d’identité :
```
jwtOptions.Authority = "https://sts.windows.net/a3942615-d115-4eb7-bc84-9974abcf5064/";
```

API minimale pour les données météorologiques

Sécurisez le point de terminaison des données de prévision météorologique dans le fichier Program du projet :

app.MapGet("/weather-forecast", () =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
}).RequireAuthorization();

La méthode d’extension RequireAuthorization nécessite une autorisation pour la définition de route. Pour les contrôleurs que vous ajoutez au projet, ajoutez l’attribut [Authorize] au contrôleur ou à l’action.

Rediriger vers la page d’accueil lors de la déconnexion

Quand un utilisateur navigue dans l’application, le composant LogInOrOut (Layout/LogInOrOut.razor) définit un champ masqué pour l’URL de retour (ReturnUrl) sur la valeur de l’URL actuelle (currentURL). Quand l’utilisateur se déconnecte de l’application, le fournisseur d’identité le renvoie à la page à partir de laquelle il s’est déconnecté.

Si l’utilisateur se déconnecte d’une page sécurisée, il est renvoyé à la même page sécurisée après la déconnexion seulement pour être renvoyé via le processus d’authentification. Ce comportement convient quand les utilisateurs doivent changer de compte fréquemment. Cependant, une autre spécification d’application peut demander à ce que l’utilisateur soit renvoyé à la page d’accueil de l’application ou à une autre page après la déconnexion. L’exemple suivant montre comment définir la page d’accueil de l’application comme URL de retour pour les opérations de déconnexion.

Les modifications importantes apportées au composant LogInOrOut sont illustrées dans l’exemple suivant. La value du champ masqué pour ReturnUrl est définie sur la page d’accueil est défini sur la page d’accueil à l’adresse /. IDisposable n’est plus implémenté. Le NavigationManager n’est plus injecté. Le bloc @code tout entier est supprimé.

Layout/LogInOrOut.razor:

@using Microsoft.AspNetCore.Authorization

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <input type="hidden" name="ReturnUrl" value="/" />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout @context.User.Identity?.Name
                </button>
            </form>
        </Authorized>
        <NotAuthorized>
            <a class="nav-link" href="authentication/login">
                <span class="bi bi-person-badge-nav-menu" aria-hidden="true"></span> 
                Login
            </a>
        </NotAuthorized>
    </AuthorizeView>
</div>

Nonce de chiffrement

Un nonce est une chaîne de caractères qui associe la session d’un client à un jeton d’identification afin d’atténuer les attaques par relecture.

Si vous recevez une erreur de nonce pendant le développement et les tests d’authentification, utilisez une nouvelle session de navigateur InPrivate/incognito pour chaque exécution de test, quelle que soit l’importance du changement apporté à l’application ou à l’utilisateur de test, car des données cookie obsolètes peuvent entraîner une erreur de nonce. Pour plus d’informations, consultez la section Cookies et les données de site.

Il n’est pas nécessaire d’utiliser un nonce lorsqu’un jeton d’actualisation est échangé contre un nouveau jeton d’accès. Dans l’exemple d’application, le CookieOidcRefresher (CookieOidcRefresher.cs) définit délibérément OpenIdConnectProtocolValidator.RequireNonce sur false.

Résolution des problèmes

Logging

L’application serveur est une application standard ASP.NET Core. Consultez les instructions de journalisation ASP.NET Core pour activer un niveau de journalisation inférieur dans l’application serveur.

Pour activer la journalisation de débogage ou de trace pour l’authentification Blazor WebAssembly, consultez la section Journalisation d’authentification côté client de la Journalisation Blazor ASP.NET Core avec le sélecteur de version d’article défini sur ASP.NET Core 7.0 ou une version ultérieure.

Erreurs courantes

Mauvaise configuration de l’application ou du fournisseur d’identité (Identity Provider)

Les erreurs les plus courantes sont provoquées par une configuration incorrecte. Voici quelques exemples :
- Selon les besoins du scénario, une autorité, une instance, un ID de locataire, un domaine de locataire, un ID client ou un URI de redirection manquant ou incorrect empêche une application d’authentifier les clients.
- Les étendues de requêtes erronées empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Des autorisations d’API serveur incorrectes ou manquantes empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Exécution de l’application sur un autre port que celui configuré dans l’URI de redirection de l’inscription d’application de l’IP. Notez qu’un port n’est pas requis pour Microsoft Entra ID et pour une application s’exécutant à une adresse de test de développement localhost. Cependant, la configuration du port de l’application et le port où l’application s’exécute doivent correspondre pour les adresses non-localhost.
La couverture de la configuration dans cet article présente des exemples de la configuration correcte. Vérifiez soigneusement la configuration à la recherche d’une application et d’une configuration incorrecte de l’adresse IP.

Si la configuration semble correcte :
- Analysez les journaux des applications.
- Examinez le trafic réseau entre l’application cliente et le fournisseur d’identité ou l’application serveur à l’aide des outils de développement du navigateur. Bien souvent, un message d’erreur exact ou un message indiquant la cause du problème est retourné au client par le fournisseur d’identité ou l’application serveur, une fois qu’une demande a été effectuée. Vous trouverez des conseils d’aide sur les outils de développement dans les articles suivants :
  - Google Chrome (documentation Google)
  - Microsoft Edge
  - Mozilla Firefox (documentation Mozilla)
L’équipe de documentation peut répondre aux commentaires et bogues relatifs aux articles (ouvrez un problème à partir de la section de commentaires de cette page). Toutefois, elle ne peut pas fournir de support produit. Plusieurs forums de support publics sont disponibles pour vous aider à résoudre les problèmes liés à une application. Nous recommandons ce qui suit :
Les forums précédents ne sont pas détenus ou contrôlés par Microsoft.

Pour les rapports de bogues de framework reproductibles, non liés à la sécurité, non sensibles et non confidentiels, ouvrez un problème auprès de l’unité de produit ASP.NET Core. N’ouvrez pas de problème auprès de l’unité de produit tant que vous n’avez pas investigué de manière approfondie la cause du problème, sans pouvoir le résoudre par vous-même ou avec l’aide de la communauté sur un forum de support public. L’unité de produit ne peut pas résoudre les problèmes d’applications individuelles qui sont défaillantes en raison d’une mauvaise configuration ou de cas d’usage impliquant des services tiers. Si un rapport est de nature sensible ou confidentielle, ou s’il décrit une faille de sécurité potentielle (exploitable par des attaquants) dans le produit, consultez Signaler des problèmes de sécurité et des bogues (référentiel GitHub dotnet/aspnetcore).
Client non autorisé pour ME-ID

Info : Échec de l’autorisation Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]. Ces conditions n’ont pas été remplies : DenyAnonymousAuthorizationRequirement : Nécessite un utilisateur authentifié.

Erreur de rappel de la connexion à partir de ME-ID :
- Erreur : unauthorized_client
- Description : AADB2C90058: The provided application is not configured to allow public clients.
Pour résoudre l’erreur :
1. Dans le portail Azure, accédez au manifeste de l’application.
2. Affectez à l’attribut allowPublicClient la valeur null ou true.

Cookies et données de site

Les Cookies et les données de site peuvent persister entre les mises à jour d’application, et interférer avec les tests et la résolution des problèmes. Effacez ce qui suit quand vous apportez des changements au code d’application, au compte d’utilisateur du fournisseur ou à la configuration de l’application :

cookies de connexion de l’utilisateur
cookies d’application
Données de site mises en cache et stockées

Il existe une approche qui permet d’empêcher les cookie et les données de site persistants d’interférer avec les tests et la résolution des problèmes. Elle consiste à :

Configurer un navigateur
- Utilisez un navigateur de test que vous pouvez configurer pour supprimer tous les cookies et toutes les données de site à chaque fois qu’il se ferme.
- Vérifiez que le navigateur est fermé manuellement ou par l’IDE chaque fois qu’un changement est apporté à la configuration de l’application, de l’utilisateur de test ou du fournisseur.
Utilisez une commande personnalisée pour ouvrir un navigateur en mode InPrivate ou Incognito dans Visual Studio :
- Ouvrez la boîte de dialogue Parcourir avec à partir du bouton Exécuter de Visual Studio.
- Cliquez sur le bouton Ajouter.
- Indiquez le chemin de votre navigateur dans le champ Programme. Les chemins d’exécutables suivants sont des emplacements d’installation classiques de Windows 10. Si votre navigateur est installé à un autre emplacement, ou si vous n’utilisez pas Windows 10, indiquez le chemin de l’exécutable du navigateur.
  - Microsoft Edge : C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
  - Google Chrome : C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
  - Mozilla Firefox : C:\Program Files\Mozilla Firefox\firefox.exe
- Dans le champ Arguments, indiquez l’option de ligne de commande utilisée par le navigateur pour qu’il s’ouvre en mode InPrivate ou Incognito. Certains navigateurs nécessitent l’URL de l’application.
  - Microsoft Edge : Utilisez -inprivate.
  - Google Chrome : Utilisez --incognito --new-window {URL}, où l’espace réservé {URL} correspond à l’URL à ouvrir (par exemple https://localhost:5001).
  - Mozilla Firefox : Utilisez -private -url {URL}, où l’espace réservé {URL} correspond à l’URL à ouvrir (par exemple https://localhost:5001).
- Indiquez un nom dans le champ Nom convivial. Par exemple, Firefox Auth Testing
- Cliquez sur le bouton OK.
- Pour éviter d’avoir à sélectionner le profil de navigateur pour chaque itération de test avec une application, définissez le profil en tant que profil par défaut avec le bouton Par défaut.
- Vérifiez que le navigateur est fermé par l’IDE chaque fois qu’un changement est apporté à la configuration de l’application, de l’utilisateur de test ou du fournisseur.

Mises à niveau d’application

Une application fonctionnelle peut échouer immédiatement après la mise à niveau du kit SDK .NET Core sur l’ordinateur de développement ou la modification des versions de package au sein de l’application. Dans certains cas, les packages incohérents peuvent bloquer une application quand vous effectuez des mises à niveau majeures. Vous pouvez résoudre la plupart de ces problèmes en suivant les instructions suivantes :

Effacez les caches de package NuGet du système local en exécutant dotnet nuget locals all --clear à partir d’un interpréteur de commandes.
Supprimez les dossiers bin et obj du projet.
Restaurez et regénérez le projet.
Supprimez tous les fichiers du dossier de déploiement sur le serveur avant de redéployer l’application.

Remarque

L’utilisation de versions de package incompatibles avec le framework cible de l’application n’est pas prise en charge. Pour plus d’informations sur un package, utilisez la Galerie NuGet ou l’Explorateur de packages FuGet.

Exécuter l’application serveur

Lors du test et de la résolution des problèmes d’application web Blazor, vérifiez que vous exécutez l’application à partir du projet de serveur.

Inspecter l’utilisateur

Le composant UserClaims suivant peut être utilisé directement dans les applications, ou servir de base à une personnalisation supplémentaire.

UserClaims.razor :

@page "/user-claims"
@using System.Security.Claims
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

@if (claims.Count() > 0)
{
    <ul>
        @foreach (var claim in claims)
        {
            <li><b>@claim.Type:</b> @claim.Value</li>
        }
    </ul>
}

@code {
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    [CascadingParameter]
    private Task<AuthenticationState>? AuthState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (AuthState == null)
        {
            return;
        }

        var authState = await AuthState;
        claims = authState.User.Claims;
    }
}

Ressources supplémentaires

Référentiel GitHub AzureAD/microsoft-identity-web : aide utile sur l’implémentation de Microsoft Identity Web pour Microsoft Entra ID et Azure Active Directory B2C pour les applications ASP.NET Core, incluant des liens vers des exemples d’applications et la documentation Azure associée. Actuellement, les applications web Blazor ne sont pas ciblées explicitement par la documentation Azure, mais l’installation et la configuration d’une application web Blazor pour ME-ID et l’hébergement Azure sont identiques à celles des applications web ASP.NET Core.
AuthenticationStateProvider service
Gérer l’état de l’authentification dans les applications web Blazor

Sécuriser une application web ASP.NET Core Blazor avec OpenID Connect (OIDC)

Exemple d’application

Projet d’application web Blazor côté serveur (BlazorWebAppOidc)

Configuration

Exemple de code d’application

Projet d’application web Blazor côté client (BlazorWebAppOidc.Client)

Avertissement quant au package en préversion

Prérequis

Exemple d’application

Projets .NET Aspire

Projet d’application web Blazor côté serveur (BlazorWebAppOidc)

Configuration

Exemple de code d’application

Projet d’application web Blazor côté client (BlazorWebAppOidc.Client)

Projet d’API web back-end (MinimalApiJwt)

Configuration

API minimale pour les données météorologiques

Rediriger vers la page d’accueil lors de la déconnexion

Nonce de chiffrement

Résolution des problèmes

Logging

Erreurs courantes

Cookies et données de site

Mises à niveau d’application

Exécuter l’application serveur

Inspecter l’utilisateur

Ressources supplémentaires

Commentaires

Ressources supplémentaires

Projet d’application web Blazor côté serveur (`BlazorWebAppOidc`)

Projet d’application web Blazor côté client (`BlazorWebAppOidc.Client`)

Projet d’application web Blazor côté serveur (`BlazorWebAppOidc`)

Projet d’application web Blazor côté client (`BlazorWebAppOidc.Client`)

Projet d’API web back-end (`MinimalApiJwt`)