Sécuriser une Blazor Web App ASP.NET Core avec OpenID Connect (OIDC)

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’Blazor Web App 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’Blazor Web App, 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’Blazor Web App.

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 de l’Blazor Web App côté serveur (BlazorWebAppOidc)

Le projet BlazorWebAppOidc est le projet côté serveur de l’Blazor Web App.

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.

Configuration

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

Établir la clé secrète client

Pour les tests de développement locaux, utilisez l’outil Gestionnaire de secrets pour stocker la clé secrète client de l’application serveur sous la clé Authentication:Schemes:MicrosoftOidc:ClientSecretde configuration.

L’exemple d’application n’a pas été initialisé pour l’outil Secret Manager. Utilisez un interpréteur de commandes, tel que l’interpréteur de commandes Developer PowerShell dans Visual Studio, pour exécuter la commande suivante. Avant d’exécuter la commande, remplacez le répertoire par le cd répertoire du projet de serveur. La commande établit un identificateur de secrets utilisateur (<UserSecretsId> dans le fichier projet de l’application serveur) :

dotnet user-secrets init

Exécutez la commande suivante pour définir la clé secrète client. L’espace {SECRET} réservé est la clé secrète client obtenue à partir de l’inscription de l’application :

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Si vous utilisez Visual Studio, vous pouvez confirmer que le secret est défini en cliquant avec le bouton droit sur le projet de serveur dans Explorateur de solutions et en sélectionnant Gérer les secrets utilisateur.

Configurer l’application

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 au middleware responsable de la conservation de l’identity 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/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (utilise l’ID de locataire aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • ID client ({CLIENT ID}) : 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  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/";
  

• 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 des revendications et les noms des revendications du JWT sont directement utilisés par l’application. L’exemple suivant définit le type de revendication de rôle sur « roles », qui est approprié pour Microsoft Entra ID (ME-ID). Consultez la documentation de votre fournisseur d’identity pour plus d’informations.

  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 = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• 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 : chemin d’accès de requête dans le chemin d’accès de base de l’application où l’agent utilisateur est renvoyé après la déconnexion du fournisseur d’identity.

    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 :

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

Projet d’Blazor Web App côté client (BlazorWebAppOidc.Client)

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

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’Blazor Web App 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’Blazor Web App 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.

Pour plus d’informations sur .NET Aspire, consultez Disponibilité générale de .NET Aspire : simplifier le développement .NET cloud natif (mai 2024).

Prérequis

.NET Aspire nécessite la version 17.10 de Visual Studio ou une version 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 .NET Aspire 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’Blazor Web App.
• BlazorWebAppOidc.Client : projet côté client de l’Blazor Web App.

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 BlazorWebAppOidcBff pour .NET 8 ou ultérieur.

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

.NET Aspire projets

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.

L’exemple d’application configure uniquement un profil de lancement HTTP non sécurisé (http) à utiliser pendant les tests de développement. Pour plus d’informations, notamment un exemple de profils de paramètres de lancement non sécurisés et sécurisés, consultez Autoriser le transport non sécurisé dans .NET Aspire (documentation .NET Aspire).

Projet de l’Blazor Web App côté serveur (BlazorWebAppOidc)

Le projet BlazorWebAppOidc est le projet côté serveur de l’Blazor Web App. 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.

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.

Configuration

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

Établir la clé secrète client

Pour les tests de développement locaux, utilisez l’outil Gestionnaire de secrets pour stocker la clé secrète client de l’application serveur sous la clé Authentication:Schemes:MicrosoftOidc:ClientSecretde configuration.

L’exemple d’application n’a pas été initialisé pour l’outil Secret Manager. Utilisez un interpréteur de commandes, tel que l’interpréteur de commandes Developer PowerShell dans Visual Studio, pour exécuter la commande suivante. Avant d’exécuter la commande, remplacez le répertoire par le cd répertoire du projet de serveur. La commande établit un identificateur de secrets utilisateur (<UserSecretsId> dans le fichier projet de l’application serveur) :

dotnet user-secrets init

Exécutez la commande suivante pour définir la clé secrète client. L’espace {SECRET} réservé est la clé secrète client obtenue à partir de l’inscription de l’application :

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Si vous utilisez Visual Studio, vous pouvez confirmer que le secret est défini en cliquant avec le bouton droit sur le projet de serveur dans Explorateur de solutions et en sélectionnant Gérer les secrets utilisateur.

Configurer l’application

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 au middleware responsable de la conservation de l’identity 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}) : 00001111-aaaa-2222-bbbb-3333cccc4444
  • Étendue configurée pour les données météorologiques provenant de MinimalApiJwt : ({API NAME}) : Weather.Get

  oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444/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}) : 00001111-aaaa-2222-bbbb-3333cccc4444
  • Étendue configurée pour les données météorologiques provenant de MinimalApiJwt : ({API NAME}) : Weather.Get

  oidcOptions.Scope.Add("api://00001111-aaaa-2222-bbbb-3333cccc4444/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/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (utilise l’ID de locataire aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • ID client ({CLIENT ID}) : 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  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/";
  

• 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 définit le type de revendication de rôle sur « roles », qui est approprié pour Microsoft Entra ID (ME-ID). Consultez la documentation de votre fournisseur d’identity pour plus d’informations.

  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 = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• 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 : chemin d’accès de requête dans le chemin d’accès de base de l’application où l’agent utilisateur est renvoyé après la déconnexion du fournisseur d’identity.

    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 :

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

Projet d’Blazor Web App côté client (BlazorWebAppOidc.Client)

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

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.

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’Blazor Web App (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}) : 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444";
  

  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}) : 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "api://00001111-aaaa-2222-bbbb-3333cccc4444";
  

• 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/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (utilise l’ID de locataire aaaabbbb-0000-cccc-1111-dddd2222eeee)

  jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/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 renvoyé par le fournisseur d’identity :

  jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
  

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.