Partager via


Sécuriser un ASP.NET Core Blazor Web App avec l’ID Microsoft Entra

Cet article décrit comment sécuriser un Blazor Web App avec la plateforme d’identité Microsoft à l’aide des packages Web MicrosoftIdentity pour Microsoft Entra ID à l’aide d’une application exemple.

Cette version de l’article traite de l’implémentation d’Entra sans adopter le modèle backend pour le serveur frontal (BFF). Le modèle BFF est pratique pour faire des requêtes authentifiées auprès de services externes. Remplacez le sélecteur de version d’article par modèle BFF si la spécification de l’application appelle à adopter le modèle BFF.

La spécification suivante est couverte :

  • Le Blazor Web App utilise le mode de rendu automatique avec interactivité globale (InteractiveAuto).
  • Le projet serveur appelle AddAuthenticationStateSerialization pour ajouter un fournisseur d’état d’authentification côté serveur qui utilise PersistentComponentState pour transmettre l’état d’authentification au client. Le client appelle AddAuthenticationStateDeserialization pour désérialiser et utiliser l'état d'authentification transmis par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
  • L'application utilise Microsoft Entra ID, basé sur les packages Web de MicrosoftIdentity.
  • L’actualisation automatique des jetons non interactifs est gérée par l’infrastructure.
  • L’application utilise des abstractions de service côté serveur et côté client pour afficher les données météorologiques générées :
    • Lors du rendu du composant Weather sur le serveur pour afficher les données météorologiques, le composant utilise le ServerWeatherForecaster. Les packages Web Microsoft Identity fournissent une API permettant de créer un service Web en aval nommé pour effectuer des appels API Web. IDownstreamApi est injecté dans le ServerWeatherForecaster, qui est utilisé pour appeler CallApiForUserAsync pour obtenir des données météorologiques à partir d’une API web externe (MinimalApiJwt projet).
    • Lorsque le Weather composant est rendu sur le client, le composant utilise l’implémentation ClientWeatherForecaster du service, qui utilise un fichier préconfiguré HttpClient (dans le fichier du Program projet client) pour effectuer un appel d’API web à l’API minimale (/weather-forecast) du projet serveur pour les données météorologiques. Le point de terminaison d’API minimal obtient les données météorologiques de la ServerWeatherForecaster classe et les retourne au client pour le rendu par le composant.

Exemple de solution

L’exemple de solution se compose des projets suivants :

  • BlazorWebAppEntra : 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.
  • BlazorWebAppEntra.Client : Projet côté client de la Blazor Web App.
  • MinimalApiJwt : API web back-end, contenant un exemple de point de terminaison d’API minimale pour les données météorologiques.

Accédez à l’exemple via le dossier de la dernière version dans le répertoire des échantillons Blazor avec le lien suivant. L’exemple se trouve dans le dossier BlazorWebAppEntra pour .NET 9 ou version ultérieure.

Démarrez la solution à partir du Aspire/Aspire.AppHost projet.

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

Inscriptions d’applications Microsoft Entra ID

Nous vous recommandons d’utiliser des inscriptions distinctes pour les applications et les API web, même lorsque les applications et les API web se trouvent dans la même solution. Les instructions suivantes concernent l’application BlazorWebAppEntra et l’API web MinimalApiJwt de l’exemple de solution, mais les mêmes conseils s’appliquent généralement aux inscriptions basées sur Entra pour les applications et les API web.

Inscrivez d’abord l’API web (MinimalApiJwt) afin que vous puissiez ensuite accorder l’accès à l’API web lors de l’inscription de l’application. L’ID de locataire et l’ID client de l’API web sont utilisés pour configurer l’API web dans son Program fichier. Après avoir inscrit l’API web, exposez l’API web dans les enregistrements> d’applicationsExposez une API avec un nom d’étendue de Weather.Get. Enregistrez l’URI d’ID d’application à utiliser dans la configuration de l’application.

Ensuite, inscrivez l’application (BlazorWebAppEntra) avec une configuration de plateforme web avec deux entrées sous URI de redirection : https://localhost/signin-oidc et https://localhost/signout-callback-oidc (les ports ne sont pas obligatoires sur ces URI). Définissez l’URL de déconnexion du canal frontal vers https://localhost/signout-callback-oidc (un port n’est pas obligatoire). L'ID de locataire, le domaine de locataire et l'ID client de l'application, ainsi que l'adresse de base de l'API web, l'URI d'ID d'application et le nom de l'étendue météorologique, sont utilisés pour configurer l'application dans son fichier appsettings.json. Accordez l’autorisation d’API pour accéder à l’API Web dans Inscriptions d’applications>Autorisations d’API. Si la spécification de sécurité de l’application l’appelle, vous pouvez accorder au administrateur le consentement de l’organisation pour accéder à l’API web. Les utilisateurs et groupes autorisés sont affectés à l’inscription de l’application dans Inscriptions d’applications>Applications d’entreprise.

Dans la configuration de l'inscription d'applications du portail Entra ou Azure pour les flux d'autorisation implicite et hybrides, ne cochez aucune case pour le point de terminaison d'autorisation renvoyant des Jetons d'accès ou des Jetons d'identité. Le gestionnaire OpenID Connect demande automatiquement les jetons appropriés à l’aide du code retourné par le point de terminaison d’autorisation.

Créez une clé secrète client dans l’inscription de l’application dans le portail Entra ou Azure (Gérer les>certificats et secrets>Nouveau secret client). Conservez le secret client Valeur pour l'utiliser dans la section suivante.

Des instructions supplémentaires sur la configuration d’Entra pour des paramètres spécifiques sont fournies plus loin dans cet article.

Projet côté serveur Blazor Web App (BlazorWebAppEntra)

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

Projet Blazor Web App côté client (BlazorWebAppEntra.Client)

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

Si l’utilisateur doit se connecter ou sortir pendant le rendu côté client, un rechargement de page complet est lancé.

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.

Le fichier MinimalApiJwt.http peut être utilisé pour tester la requête de données météorologiques. Notez que le projet MinimalApiJwt 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.

Le projet inclut des packages et une configuration pour produire des documents OpenAPI.

Un point de terminaison de données de prévision météorologique sécurisé se trouve dans le fichier du Program 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.

Configurer le projet d’API web back-end (MinimalApiJwt)

Configurez le projet dans le JwtBearerOptions de l’appel AddJwtBearer dans le fichier MinimalApiJwt du projet Program.

Pour l’inscription de l’application API web, l’étendue Weather.Get est configurée dans le portail Entra ou Azure dans Exposer une API.

Authority définit l’autorité pour effectuer des appels OIDC.

jwtOptions.Authority = "{AUTHORITY}";

Les exemples suivants utilisent un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee et un nom de répertoire de contoso.

Si l’application est enregistrée dans un locataire ME-ID, l’autorité doit correspondre à l’émetteur (iss) du JWT retourné par le fournisseur d’identité :

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

Si l’application est enregistrée dans un tenant Microsoft Entra ID externe :

jwtOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";

Si l'application est enregistrée dans un locataire AAD B2C :

jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";

Note

Azure Active Directory B2C n’est plus disponible en tant que service pour les nouveaux clients depuis le 1er mai 2025. Les locataires AAD B2C sont pris en charge pour les clients disposant de comptes établis avant le 1er mai 2025 jusqu’en 2030. Pour plus d’informations, consultez Azure AD B2C : Foire aux questions (FAQ).

Audience définit l’audience pour tout jeton d’accès JWT reçu.

jwtOptions.Audience = "{AUDIENCE}";

Faire correspondre la valeur uniquement au chemin de l’URI d’ID d’application configuré lors de l’ajout de l’étendue Weather.Get sous Exposer une API dans le portail Entra ou Azure. N’incluez pas le nom de l’étendue , «Weather.Get », dans la valeur.

Les exemples suivants utilisent un ID d’application (client) de 11112222-bbbb-3333-cccc-4444dddd5555. Le troisième exemple utilise un domaine de locataire de contoso.onmicrosoft.com.

Exemple de locataire ME-ID :

jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";

Microsoft Entra ID externe du locataire :

jwtOptions.Audience = "11112222-bbbb-3333-cccc-4444dddd5555";

Exemple de locataire AAD B2C :

jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";

Configurer le projet de serveur (BlazorWebAppEntra)

AddMicrosoftIdentityWebApp à partir de Microsoft WebIdentity (package NuGetMicrosoft.Identity.Web, documentation API) est configuré dans le fichier BlazorWebAppEntra du projet Program.

Obtenez l’ID d’application (client), le domaine de locataire (éditeur) et l’ID d’annuaire (locataire) de l’application à partir de l’inscription de l’application dans le portail Entra ou Azure. L’URI de l’ID d’application est obtenu pour l’étendue Weather.Get à partir de l’enregistrement de l’API Web. N’incluez pas le nom de l’étendue lorsque vous récupérez l’URI de l’ID d’application à partir du portail.

La configuration de l’authentification dépend du type de locataire :

Configuration du locataire ME-ID

Cette section s’applique à une application inscrite dans une instance Microsoft Entra ID ou un locataire Azure Active Directory B2C.

Dans le fichier BlazorWebAppEntra du projet Program, indiquez les valeurs des espaces réservés ci-dessous dans la configuration web de Microsoft Identity :

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
        msIdentityOptions.Domain = "{DIRECTORY NAME}.onmicrosoft.com";
        msIdentityOptions.Instance = "https://login.microsoftonline.com/";
        msIdentityOptions.ResponseType = "code";
        msIdentityOptions.TenantId = "{TENANT ID}";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "{BASE ADDRESS}";
        configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Espaces réservés dans la configuration précédente :

  • {CLIENT ID (BLAZOR APP)}: ID d’application (client).
  • {DIRECTORY NAME}: nom du répertoire du domaine du locataire (éditeur).
  • {TENANT ID} : ID d’annuaire (locataire).
  • {BASE ADDRESS}: adresse de base de l’API web.
  • {APP ID URI}: URI de l'ID de l'application pour les scopes d'API web. L’un des formats suivants est utilisé, où l’espace réservé {CLIENT ID (WEB API)} correspond à l’ID client de l’enregistrement Entra de l’API Web et l’espace réservé {DIRECTORY NAME} correspond au nom du répertoire du domaine du locataire (éditeurs) (exemple : contoso).
    • Format de locataire ME-ID : api://{CLIENT ID (WEB API)}
    • Format de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}

Example:

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
        msIdentityOptions.Domain = "contoso.onmicrosoft.com";
        msIdentityOptions.Instance = "https://login.microsoftonline.com/";
        msIdentityOptions.ResponseType = "code";
        msIdentityOptions.TenantId = "aaaabbbb-0000-cccc-1111-dddd2222eeee";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "https://localhost:7277";
        configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Configuration de l’ID externe Microsoft Entra

Cette section s’applique à une application enregistrée dans un locataire Microsoft Entra External ID.

Dans le fichier BlazorWebAppEntra du projet Program, indiquez les valeurs des espaces réservés ci-dessous dans la configuration web de Microsoft Identity :

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.Authority = "https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0";
        msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
        msIdentityOptions.ResponseType = "code";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "{BASE ADDRESS}";
        configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Espaces réservés dans la configuration précédente :

  • {DIRECTORY NAME}: nom du répertoire du domaine du locataire (éditeur).
  • {CLIENT ID (BLAZOR APP)}: ID d’application (client).
  • {BASE ADDRESS}: adresse de base de l’API web.
  • {APP ID URI}: URI de l'ID de l'application pour les scopes d'API web. L’un des formats suivants est utilisé, où l’espace {CLIENT ID (WEB API)} réservé est l’ID client de l’inscription Entra de l’API web, et l’espace {DIRECTORY NAME} réservé est le nom du répertoire du domaine client (éditeur) (exemple : contoso).
    • ME-ID ou format de locataire Microsoft Entra External ID : api://{CLIENT ID (WEB API)}
    • Format de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}

Example:

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
        msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
        msIdentityOptions.ResponseType = "code";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "https://localhost:7277";
        configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Le chemin de rappel (CallbackPath) doit correspondre à l’URI de redirection (chemin de rappel de connexion) configuré lors de l’inscription de l’application dans l’Entra ou Portail Azure. Les chemins sont configurés dans le panneau d'authentification de l'inscription de l'application. La valeur par défaut de CallbackPath est /signin-oidc pour un URI de redirection inscrit https://localhost/signin-oidc (un port n’est pas obligatoire).

SignedOutCallbackPath correspond au chemin de requête dans le chemin de base de l’application intercepté par le gestionnaire OpenID Connect où l’agent utilisateur est renvoyé en premier après la déconnexion d’Entra. L’exemple d’application ne définit pas de valeur pour le chemin d’accès, car la valeur par défaut «/signout-callback-oidc» est utilisée. Après avoir intercepté la requête, le gestionnaire OpenID Connect redirige vers le SignedOutRedirectUri ou le RedirectUri, s’il est spécifié.

Warning

Ne stockez pas les secrets d’application, les chaîne de connexion, les informations d’identification, les mots de passe, les numéros d’identification personnels (PIN), le code C#/.NET privé ou les clés/jetons privés dans le code côté client, qui est toujours non sécurisé. Dans les environnements de test/intermédiaire et de production, le code côté Blazor serveur et les API web doivent utiliser des flux d’authentification sécurisés qui évitent de conserver les informations d’identification dans le code du projet ou les fichiers de configuration. En dehors des tests de développement locaux, nous vous recommandons d’éviter l’utilisation de variables d’environnement pour stocker des données sensibles, car les variables d’environnement ne sont pas l’approche la plus sécurisée. Pour les tests de développement locaux, l’outil Secret Manager est recommandé pour sécuriser les données sensibles. Pour plus d’informations, consultez Gestion sécurisée des données sensibles et des informations d’identification.

Cette version de l’article traite de l’implémentation d’Entra avec le modèle Back-end pour le serveur frontal (BFF). Modifiez le sélecteur de version d’article en modèle Non-BFF si la spécification de l’application n’appelle pas l’adoption du modèle BFF.

La spécification suivante est couverte :

  • Le Blazor Web App utilise le mode de rendu automatique avec interactivité globale (InteractiveAuto).
  • Le projet serveur appelle AddAuthenticationStateSerialization pour ajouter un fournisseur d’état d’authentification côté serveur qui utilise PersistentComponentState pour transmettre l’état d’authentification au client. Le client appelle AddAuthenticationStateDeserialization pour désérialiser et utiliser l'état d'authentification transmis par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
  • L'application utilise Microsoft Entra ID, basé sur les packages Web de MicrosoftIdentity.
  • L’actualisation automatique des jetons non interactifs est gérée par l’infrastructure.
  • Le modèle BFF (Backend for Frontend) est adopté en utilisant 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 dorsale utilise l'authentification par porteur JWT pour valider les jetons JWT enregistrés par Blazor Web App lors de la connexion cookie.
    • 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.
  • L’application utilise des abstractions de service côté serveur et côté client pour afficher les données météorologiques générées.
    • Lors du rendu du composant Weather sur le serveur pour afficher les données météorologiques, le composant utilise le ServerWeatherForecaster. Les packages Web Microsoft Identity fournissent une API permettant de créer un service Web en aval nommé pour effectuer des appels API Web. IDownstreamApi est injecté dans le ServerWeatherForecaster, qui est utilisé pour appeler CallApiForUserAsync pour obtenir des données météorologiques à partir d’une API web externe (MinimalApiJwt projet).
    • Lorsque le Weather composant est rendu sur le client, le composant utilise l’implémentation ClientWeatherForecaster du service, qui utilise un fichier préconfiguré HttpClient (dans le fichier du Program projet client) pour effectuer un appel d’API web à l’API minimale (/weather-forecast) du projet serveur pour les données météorologiques. L'endpoint d'API minimal obtient un jeton d'accès pour l'utilisateur en appelant GetAccessTokenForUserAsync. En plus des étendues correctes, un appel proxy inverse est effectué vers l’API Web externe (projet MinimalApiJwt) afin d’obtenir et de renvoyer les données météorologiques au client pour qu’elles soient rendues par le composant.

Prerequisites

Aspire nécessite la version 17.10 de Visual Studio ou une version ultérieure

Consultez également la section Prérequis du guide de démarrage rapide : Créer votre première Aspire solution.

Exemple de solution

L’exemple de solution se compose des projets suivants :

  • Aspire:
    • Aspire.AppHost: permet de gérer les problèmes d’orchestration de haut niveau de l’application.
    • Aspire.ServiceDefaults : contient les configurations d’application 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.
  • BlazorWebAppEntra: Projet côté serveur du Blazor Web App.
  • BlazorWebAppEntra.Client : Projet côté client de la Blazor Web App.

Accédez à l’exemple via le dossier de la dernière version dans le répertoire des échantillons Blazor avec le lien suivant. L’exemple se trouve dans le dossier BlazorWebAppEntraBff pour .NET 9 ou version ultérieure.

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

Inscriptions d’applications Microsoft Entra ID

Nous vous recommandons d’utiliser des inscriptions distinctes pour les applications et les API web, même lorsque les applications et les API web se trouvent dans la même solution. Les instructions suivantes concernent l’application BlazorWebAppEntra et l’API web MinimalApiJwt de l’exemple de solution, mais les mêmes conseils s’appliquent généralement aux inscriptions basées sur Entra pour les applications et les API web.

Inscrivez d’abord l’API web (MinimalApiJwt) afin que vous puissiez ensuite accorder l’accès à l’API web lors de l’inscription de l’application. L’ID de locataire et l’ID client de l’API web sont utilisés pour configurer l’API web dans son Program fichier. Après avoir inscrit l’API web, exposez l’API web dans les enregistrements> d’applicationsExposez une API avec un nom d’étendue de Weather.Get. Enregistrez l’URI d’ID d’application à utiliser dans la configuration de l’application.

Ensuite, inscrivez l’application (BlazorWebAppEntra) avec une configuration de plateforme web avec deux entrées sous URI de redirection : https://localhost/signin-oidc et https://localhost/signout-callback-oidc (les ports ne sont pas obligatoires sur ces URI). L'ID de locataire, le domaine de locataire et l'ID client de l'application, ainsi que l'adresse de base de l'API web, l'URI d'ID d'application et le nom de l'étendue météorologique, sont utilisés pour configurer l'application dans son fichier appsettings.json. Accordez l’autorisation d’API pour accéder à l’API Web dans Inscriptions d’applications>Autorisations d’API. Si la spécification de sécurité de l’application l’appelle, vous pouvez accorder au administrateur le consentement de l’organisation pour accéder à l’API web. Les utilisateurs et groupes autorisés sont affectés à l’inscription de l’application dans Inscriptions d’applications>Applications d’entreprise.

Dans la configuration de l'inscription d'applications du portail Entra ou Azure pour les flux d'autorisation implicite et hybrides, ne cochez aucune case pour le point de terminaison d'autorisation renvoyant des Jetons d'accès ou des Jetons d'identité. Le gestionnaire OpenID Connect demande automatiquement les jetons appropriés à l’aide du code retourné par le point de terminaison d’autorisation.

Créez une clé secrète client dans l’inscription de l’application dans le portail Entra ou Azure (Gérer les>certificats et secrets>Nouveau secret client). Conservez le secret client Valeur pour l'utiliser dans la section suivante.

Des instructions supplémentaires sur la configuration d’Entra pour des paramètres spécifiques sont fournies plus loin dans cet article.

Aspire projets

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

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

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 Aspire (documentation Aspire).

Projet côté serveur Blazor Web App (BlazorWebAppEntra)

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

Projet Blazor Web App côté client (BlazorWebAppEntra.Client)

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

Si l’utilisateur doit se connecter ou sortir pendant le rendu côté client, un rechargement de page complet est lancé.

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 (BlazorWebAppEntra) sont proxysées vers le projet MinimalApiJwt.

Le fichier MinimalApiJwt.http peut être utilisé pour tester la requête de données météorologiques. Notez que le projet MinimalApiJwt 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.

Le projet inclut des packages et une configuration pour produire des documents OpenAPI.

Un point de terminaison de données de prévision météorologique sécurisé se trouve dans le fichier du Program 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.

Configurer le projet d’API web back-end (MinimalApiJwt)

Configurez le projet MinimalApiJwt dans le JwtBearerOptions de l’appel AddJwtBearer dans le fichier Program du projet.

Pour l’inscription de l’application API web, l’étendue Weather.Get est configurée dans le portail Entra ou Azure dans Exposer une API.

Authority définit l’autorité pour effectuer des appels OIDC.

jwtOptions.Authority = "{AUTHORITY}";

Les exemples suivants utilisent un ID de locataire aaaabbbb-0000-cccc-1111-dddd2222eeee et un nom de répertoire contoso.

Si l’application est enregistrée dans un locataire ME-ID, l’autorité doit correspondre à l’émetteur (iss) du JWT retourné par le fournisseur d’identité :

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

Si l’application est inscrite dans une instance Microsoft Entra External ID :

jwtOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";

Si l'application est enregistrée dans un locataire AAD B2C :

jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";

Note

Azure Active Directory B2C n’est plus disponible en tant que service pour les nouveaux clients depuis le 1er mai 2025. Les locataires AAD B2C sont pris en charge pour les clients disposant de comptes établis avant le 1er mai 2025 jusqu’en 2030. Pour plus d’informations, consultez Azure AD B2C : Foire aux questions (FAQ).

Audience définit l’audience pour tout jeton d’accès JWT reçu.

jwtOptions.Audience = "{AUDIENCE}";

Faire correspondre la valeur uniquement au chemin de l’URI d’ID d’application configuré lors de l’ajout de l’étendue Weather.Get sous Exposer une API dans le portail Entra ou Azure. N’incluez pas le nom de l’étendue , «Weather.Get », dans la valeur.

Les exemples suivants utilisent un ID d’application (client) de 11112222-bbbb-3333-cccc-4444dddd5555. Le troisième exemple utilise un domaine client de contoso.onmicrosoft.com.

Exemple de locataire ME-ID :

jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";

Locataire d’ID externe Microsoft Entra :

jwtOptions.Audience = "11112222-bbbb-3333-cccc-4444dddd5555";

Exemple de locataire AAD B2C :

jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";

Configurer le projet de serveur (BlazorWebAppEntra)

AddMicrosoftIdentityWebApp à partir de Microsoft WebIdentity (package NuGetMicrosoft.Identity.Web, documentation API) est configuré dans le fichier BlazorWebAppEntra du projet Program.

Obtenez l’ID d’application (client), le domaine de locataire (éditeur) et l’ID d’annuaire (locataire) de l’application à partir de l’inscription de l’application dans le portail Entra ou Azure. L’URI de l’ID d’application est obtenu pour l’étendue Weather.Get à partir de l’enregistrement de l’API Web. N’incluez pas le nom de l’étendue lorsque vous récupérez l’URI de l’ID d’application à partir du portail.

La configuration de l’authentification dépend du type de locataire :

configuration du client ME-ID

Cette section s’applique à une application inscrite dans un Microsoft Entra ID ou un tenant Azure AD B2C.

Dans le fichier BlazorWebAppEntra du projet Program, indiquez les valeurs des espaces réservés ci-dessous dans la configuration web de Microsoft Identity :

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
        msIdentityOptions.Domain = "{DIRECTORY NAME}.onmicrosoft.com";
        msIdentityOptions.Instance = "https://login.microsoftonline.com/";
        msIdentityOptions.ResponseType = "code";
        msIdentityOptions.TenantId = "{TENANT ID}";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "{BASE ADDRESS}";
        configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Fournissez la même étendue d’API en aval au transformateur de requête :

List<string> scopes = ["{APP ID URI}/Weather.Get"];

Espaces réservés dans la configuration précédente :

  • {CLIENT ID (BLAZOR APP)}: ID d’application (client).
  • {DIRECTORY NAME}: nom du répertoire du domaine du locataire (éditeur).
  • {TENANT ID} : ID d’annuaire (locataire).
  • {BASE ADDRESS}: adresse de base de l’API web.
  • {APP ID URI}: URI de l'ID de l'application pour les scopes d'API web. L’un des formats suivants est utilisé, où l’espace réservé {CLIENT ID (WEB API)} correspond à l’ID client de l’enregistrement Entra de l’API Web et l’espace réservé {DIRECTORY NAME} correspond au nom du répertoire du domaine du locataire (éditeurs) (exemple : contoso).
    • Format de locataire ME-ID : api://{CLIENT ID (WEB API)}
    • Format de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}

Example:

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
        msIdentityOptions.Domain = "contoso.onmicrosoft.com";
        msIdentityOptions.Instance = "https://login.microsoftonline.com/";
        msIdentityOptions.ResponseType = "code";
        msIdentityOptions.TenantId = "aaaabbbb-0000-cccc-1111-dddd2222eeee";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "https://localhost:7277";
        configOptions.Scopes = 
            ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Example:

List<string> scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];

Configuration de l’ID externe Microsoft Entra

Cette section s’applique à une application inscrite dans un locataire Microsoft Entra External ID.

Dans le fichier BlazorWebAppEntra du projet Program, indiquez les valeurs des espaces réservés ci-dessous dans la configuration web de Microsoft Identity :

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.Authority = "https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0";
        msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
        msIdentityOptions.ResponseType = "code";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "{BASE ADDRESS}";
        configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Fournissez la même étendue d’API en aval au transformateur de requête :

List<string> scopes = ["{APP ID URI}/Weather.Get"];

Espaces réservés dans la configuration précédente :

  • {DIRECTORY NAME}: nom du répertoire du domaine du locataire (éditeur).
  • {CLIENT ID (BLAZOR APP)}: ID d’application (client).
  • {BASE ADDRESS}: adresse de base de l’API web.
  • {APP ID URI}: URI de l'ID de l'application pour les scopes d'API web. L’un des formats suivants est utilisé, où l’espace réservé {CLIENT ID (WEB API)} correspond à l’ID client de l’enregistrement Entra de l’API Web et l’espace réservé {DIRECTORY NAME} correspond au nom du répertoire du domaine du locataire (éditeurs) (exemple : contoso).
    • ME-ID ou format du client Microsoft Entra External ID : api://{CLIENT ID (WEB API)}
    • Format de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}

Example:

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(msIdentityOptions =>
    {
        msIdentityOptions.CallbackPath = "/signin-oidc";
        msIdentityOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
        msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
        msIdentityOptions.ResponseType = "code";
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamApi("DownstreamApi", configOptions =>
    {
        configOptions.BaseUrl = "https://localhost:7277";
        configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
    })
    .AddDistributedTokenCaches();

Example:

List<string> scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];

Warning

Les applications de production doivent utiliser un fournisseur de cache de jeton distribué de production. Sinon, l’application peut avoir des performances médiocres dans certains scénarios. Pour plus d’informations, consultez la section Utiliser un fournisseur de cache de jeton distribué de production .

Le chemin de rappel (CallbackPath) doit correspondre à l’URI de redirection (chemin de rappel de connexion) configuré lors de l’inscription de l’application dans l’Entra ou Portail Azure. Les chemins sont configurés dans le panneau d'authentification de l'inscription de l'application. La valeur par défaut de CallbackPath est /signin-oidc pour un URI de redirection inscrit https://localhost/signin-oidc (un port n’est pas obligatoire).

SignedOutCallbackPath correspond au chemin de requête dans le chemin de base de l’application intercepté par le gestionnaire OpenID Connect où l’agent utilisateur est renvoyé en premier après la déconnexion d’Entra. L’exemple d’application ne définit pas de valeur pour le chemin d’accès, car la valeur par défaut «/signout-callback-oidc» est utilisée. Après avoir intercepté la requête, le gestionnaire OpenID Connect redirige vers le SignedOutRedirectUri ou le RedirectUri, s’il est spécifié.

Warning

Ne stockez pas les secrets d’application, les chaîne de connexion, les informations d’identification, les mots de passe, les numéros d’identification personnels (PIN), le code C#/.NET privé ou les clés/jetons privés dans le code côté client, qui est toujours non sécurisé. Dans les environnements de test/intermédiaire et de production, le code côté Blazor serveur et les API web doivent utiliser des flux d’authentification sécurisés qui évitent de conserver les informations d’identification dans le code du projet ou les fichiers de configuration. En dehors des tests de développement locaux, nous vous recommandons d’éviter l’utilisation de variables d’environnement pour stocker des données sensibles, car les variables d’environnement ne sont pas l’approche la plus sécurisée. Pour les tests de développement locaux, l’outil Secret Manager est recommandé pour sécuriser les données sensibles. Pour plus d’informations, consultez Gestion sécurisée des données sensibles et des informations d’identification.

Établir la clé secrète client

Cette section s’applique uniquement au projet serveur du Blazor Web App.

Utilisez l’une ou l’autre des approches suivantes pour fournir la clé secrète client à l’application :

  • Outil Secret Manager : l’outil Secret Manager stocke les données privées sur l’ordinateur local et est utilisé uniquement pendant le développement local.
  • Azure Key Vault : vous pouvez stocker la clé secrète client dans un coffre de clés à utiliser dans n’importe quel environnement, y compris pour l’environnement de développement lors de l’utilisation locale. Certains développeurs préfèrent utiliser des coffres de clés pour les déploiements intermédiaires et de production et utiliser l’outil Secret Manager pour le développement local.

Nous vous recommandons vivement d’éviter de stocker les secrets client dans le code du projet ou les fichiers de configuration. Utilisez des flux d’authentification sécurisés, tels que l’une ou l’autre des approches de cette section.

Outil Gestionnaire de secrets

L’outil Gestionnaire de secrets peut stocker la clé secrète client de l’application serveur sous la clé AzureAd:ClientSecretde configuration.

L’application Blazor serveur n’a pas été initialisée pour l’outil Gestionnaire de secrets. 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, changez de répertoire pour le projet de serveur avec la commande cd. La commande établit un identificateur de secrets utilisateur (<UserSecretsId>) dans le fichier projet de l’application serveur, qui est utilisé en interne par l’outil pour suivre les secrets de l’application :

dotnet user-secrets init

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

dotnet user-secrets set "AzureAd:ClientSecret" "{SECRET}"

Si vous utilisez Visual Studio, vous pouvez vérifier 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.

Azure Key Vault

Azure Key Vault offre une approche sécurisée pour fournir la clé secrète client de l’application à l’application.

Pour créer un coffre de clés et définir une clé secrète client, consultez À propos des secrets Azure Key Vault (documentation Azure), qui relient les ressources pour commencer à utiliser Azure Key Vault. Pour implémenter le code de cette section, enregistrez l’URI du coffre de clés et le nom du secret à partir d’Azure lorsque vous créez le coffre de clés et le secret. Pour l’exemple de cette section, le nom du secret est «BlazorWebAppEntraClientSecret ».

Lors de la création du coffre-fort de clés dans Entra ou le portail Azure :

  • Configurez le coffre-fort de clés pour utiliser le contrôle d’accès basé sur les rôles Azure (RABC). Si vous n’utilisez pas de réseau virtuel Azure, notamment pour le développement et le test locaux, vérifiez que l’accès public à l’étape réseau est activé (activé). L’activation de l’accès public expose uniquement le point de terminaison du coffre-fort de clés. Les comptes authentifiés sont toujours requis pour l’accès.

  • Créez une instance gérée Azure Identity (ou ajoutez un rôle à l’instance gérée Identity existante à utiliser) avec le rôle Utilisateur des secrets Key Vault. Affectez le service managé Identity à l'Azure App Service qui héberge le déploiement : Paramètres>Identity>Utilisateur affecté>Ajouter.

    Note

    Si vous envisagez également d’exécuter une application localement avec un utilisateur autorisé pour l’accès au coffre de clés à l’aide d’Azure CLI ou de l’authentification du service Azure de Visual Studio, ajoutez votre compte d’utilisateur Azure développeur dans Access Control (IAM) avec le rôle Utilisateur secrets Key Vault . Si vous souhaitez utiliser Azure CLI via Visual Studio, exécutez la az login commande à partir du panneau Développeur PowerShell et suivez les invites pour vous authentifier auprès du locataire.

Pour implémenter le code de cette section, enregistrez l’URI du coffre de clés (par exemple : «https://contoso.vault.azure.net/ », barre oblique de fin requise) et le nom du secret (exemple : «BlazorWebAppEntraClientSecret ») à partir d’Azure lorsque vous créez le coffre de clés et le secret.

Important

Une clé secrète du coffre-fort est créée avec une date d'expiration. Veillez à suivre la date d'expiration d'un secret de Key Vault et à créer un nouveau secret pour l'application avant que celle-ci n'expire.

Ajoutez la classe AzureHelper suivante au projet de serveur. La méthode GetKeyVaultSecret récupère un secret à partir d'un coffre de clés. Ajustez l’espace de noms (BlazorSample.Helpers) pour qu’il corresponde au schéma d’espace de noms de votre projet.

Helpers/AzureHelper.cs :

using Azure.Core;
using Azure.Security.KeyVault.Secrets;

namespace BlazorWebAppEntra.Helpers;

public static class AzureHelper
{
    public static string GetKeyVaultSecret(string vaultUri, 
        TokenCredential credential, string secretName)
    {
        var client = new SecretClient(new Uri(vaultUri), credential);
        var secret = client.GetSecretAsync(secretName).Result;

        return secret.Value.Value;
    }
}

Note

L’exemple précédent utilise DefaultAzureCredential pour simplifier l’authentification lors du développement d’applications qui se déploient sur Azure en combinant les informations d’identification utilisées dans les environnements d’hébergement Azure avec les informations d’identification utilisées dans le développement local. Lors du passage en production, il est préférable d’opter pour une alternative, telle que ManagedIdentityCredential. Pour plus d’informations, consultez Authentifier les applications .NET hébergées par Azure auprès des ressources Azure à l’aide d’une identité managée affectée par le système.

Où les services sont inscrits dans le fichier du Program projet de serveur, obtenez et appliquez la clé secrète client à l’aide du code suivant :

TokenCredential? credential;

if (builder.Environment.IsProduction())
{
    credential = new ManagedIdentityCredential("{MANAGED IDENTITY CLIENT ID}");
}
else
{
    // Local development and testing only
    DefaultAzureCredentialOptions options = new()
    {
        // Specify the tenant ID to use the dev credentials when running the app locally
        // in Visual Studio.
        VisualStudioTenantId = "{TENANT ID}",
        SharedTokenCacheTenantId = "{TENANT ID}"
    };

    credential = new DefaultAzureCredential(options);
}

MicrosoftIdentityOptions sont définis, appelez GetKeyVaultSecret pour recevoir et affecter la clé secrète client de l’application :

msIdentityOptions.ClientSecret = AzureHelper.GetKeyVaultSecret("{VAULT URI}", 
    credential, "{SECRET NAME}");

{MANAGED IDENTITY CLIENT ID} : ID client Azure Managed Identity (GUID).

{TENANT ID} : ID d’annuaire (locataire). Exemple : aaaabbbb-0000-cccc-1111-dddd2222eeee

{VAULT URI} : URI de coffre de clés. Assurez-vous de saisir la barre oblique finale dans l'URI. Exemple : https://contoso.vault.azure.net/

{SECRET NAME} : nom du secret. Exemple : BlazorWebAppEntraClientSecret

La configuration est utilisée pour faciliter l’approvisionnement de coffres de clés dédiés et de noms de secrets en fonction des fichiers de configuration environnementaux de l’application. Par exemple, vous pouvez fournir différentes valeurs de configuration pour appsettings.Development.json le développement, appsettings.Staging.json lors de la préproduction et appsettings.Production.json pour le déploiement de production. Pour plus d’informations, consultez Configuration d’ASP.NET Core Blazor.

Sérialisez uniquement les revendications de nom et de rôle.

Dans le Program fichier, toutes les revendications sont sérialisées en définissant SerializeAllClaims sur true. Si vous souhaitez uniquement que les revendications de nom et de rôle soient sérialisées pour CSR, supprimez l’option ou définissez-la sur false.

Fournir la configuration avec le fournisseur de configuration JSON (paramètres de l’application)

Les projets de solution d’exemple configurent l’authentification Microsoft Identity Web et JWT bearer dans leurs fichiers Program afin de rendre les paramètres de configuration détectables à l’aide de la saisie semi-automatique C#. Les applications professionnelles utilisent généralement un fournisseur de configuration pour configurer des options OIDC, telles que le fournisseur de configuration JSON par défaut. Le fournisseur de configuration JSON charge la configuration à partir de fichiers appsettings.json/appsettings.{ENVIRONMENT}.jsonde paramètres d’application, où l’espace réservé est l’environnement {ENVIRONMENT}d’exécution de l’application. Suivez les instructions de cette section pour utiliser les fichiers de paramètres d’application pour la configuration.

Dans le fichier de paramètres de l’application (appsettings.json) du BlazorWebAppEntra projet, ajoutez la configuration JSON suivante :

{
  "AzureAd": {
    "CallbackPath": "/signin-oidc",
    "ClientId": "{CLIENT ID (BLAZOR APP)}",
    "Domain": "{DIRECTORY NAME}.onmicrosoft.com",
    "Instance": "https://login.microsoftonline.com/",
    "ResponseType": "code",
    "TenantId": "{TENANT ID}"
  },
  "DownstreamApi": {
    "BaseUrl": "{BASE ADDRESS}",
    "Scopes": ["{APP ID URI}/Weather.Get"]
  }
}

Mettez à jour les espaces réservés dans la configuration précédente pour qu’ils correspondent aux valeurs que l’application utilise dans le Program fichier :

  • {CLIENT ID (BLAZOR APP)}: ID d’application (client).
  • {DIRECTORY NAME}: nom du répertoire du domaine du locataire (éditeur).
  • {TENANT ID} : ID d’annuaire (locataire).
  • {BASE ADDRESS}: adresse de base de l’API web.
  • {APP ID URI}: URI de l'ID de l'application pour les scopes d'API web. L’un des formats suivants est utilisé, où l’espace réservé {CLIENT ID (WEB API)} correspond à l’ID client de l’enregistrement Entra de l’API Web et l’espace réservé {DIRECTORY NAME} correspond au nom du répertoire du domaine du locataire (éditeurs) (exemple : contoso).
    • Format de locataire ME-ID : api://{CLIENT ID (WEB API)}
    • Format de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}

Example:

"AzureAd": {
  "CallbackPath": "/signin-oidc",
  "ClientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "Domain": "contoso.onmicrosoft.com",
  "Instance": "https://login.microsoftonline.com/",
  "ResponseType": "code",
  "TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
},
"DownstreamApi": {
  "BaseUrl": "https://localhost:7277",
  "Scopes": ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"]
}

Mettez à jour toutes les autres valeurs de la configuration précédente pour qu’elles correspondent aux valeurs personnalisées/non par défaut utilisées dans le Program fichier.

La configuration est automatiquement récupérée par le générateur d’authentification.

Apportez les modifications suivantes dans le fichier Program :

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
-   .AddMicrosoftIdentityWebApp(msIdentityOptions =>
-   {
-       msIdentityOptions.CallbackPath = "...";
-       msIdentityOptions.ClientId = "...";
-       msIdentityOptions.Domain = "...";
-       msIdentityOptions.Instance = "...";
-       msIdentityOptions.ResponseType = "...";
-       msIdentityOptions.TenantId = "...";
-   })
+   .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
-   .AddDownstreamApi("DownstreamApi", configOptions =>
-   {
-       configOptions.BaseUrl = "...";
-       configOptions.Scopes = ["..."];
-   })
+   .AddDownstreamApi("DownstreamApi", builder.Configuration.GetSection("DownstreamApi"))
    .AddDistributedTokenCaches();
- List<string> scopes = ["{APP ID URI}/Weather.Get"];
- var accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes);
+ var configuration = transformContext.HttpContext.RequestServices.GetRequiredService<IConfiguration>();
+ var scopes = configuration.GetSection("DownstreamApi:Scopes").Get<IEnumerable<string>>();
+ var accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes ??
+     throw new InvalidOperationException("No downstream API scopes!"));

Note

Les applications de production doivent utiliser un fournisseur de cache de jeton distribué de production. Sinon, l’application peut avoir des performances médiocres dans certains scénarios. Pour plus d’informations, consultez la section Utiliser un fournisseur de cache de jeton distribué de production .

Dans le MinimalApiJwt projet, ajoutez la configuration des paramètres d’application suivante au appsettings.json fichier :

"Authentication": {
  "Schemes": {
    "Bearer": {
      "Authority": "https://sts.windows.net/{TENANT ID (WEB API)}",
      "ValidAudiences": ["{APP ID URI (WEB API)}"]
    }
  }
},

Mettez à jour les espaces réservés dans la configuration précédente pour qu’ils correspondent aux valeurs que l’application utilise dans le Program fichier :

  • {TENANT ID (WEB API)}: ID de locataire de l’API web.
  • {APP ID URI (WEB API)}: URI d’ID d’application de l’API web.

Les formats d’autorité adoptent les modèles suivants :

  • Type de locataire ME-ID : https://sts.windows.net/{TENANT ID}
  • ID externe Microsoft Entra : https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0
  • Type de locataire B2C : https://login.microsoftonline.com/{TENANT ID}/v2.0

Les formats d’audience adoptent les modèles suivants ({CLIENT ID} est l’ID client de l’API web ; {DIRECTORY NAME} est le nom du répertoire, par exemple) contoso:

  • Type de locataire ME-ID : api://{CLIENT ID}
  • ID externe Microsoft Entra : {CLIENT ID}
  • Type de locataire B2C : https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}

La configuration est automatiquement récupérée par le générateur d’authentification du porteur JWT.

Supprimez les lignes suivantes du Program fichier :

- jwtOptions.Authority = "...";
- jwtOptions.Audience = "...";

Pour plus d’informations sur la configuration, consultez les ressources suivantes :

Utiliser un fournisseur de cache de jeton distribué de production

Les caches de jetons distribués en mémoire sont créés lors de l’appel AddDistributedTokenCaches pour vous assurer qu’il existe une implémentation de base disponible pour la mise en cache des jetons distribués.

Les applications web de production et les API web doivent utiliser un cache de jetons distribué de production (par exemple : Redis, Microsoft SQL Server, Microsoft Azure Cosmos DB).

Note

Pour le développement et le test locaux sur une seule machine, vous pouvez utiliser des caches de jetons en mémoire plutôt que des caches de jetons distribués :

builder.Services.AddInMemoryTokenCaches();

Plus loin dans la période de développement et de test, adoptez un fournisseur de cache de jetons distribués de production.

AddDistributedMemoryCache ajoute une implémentation par défaut de IDistributedCache qui stocke les éléments de cache en mémoire. Ceci est utilisé par Microsoft Identity Web pour la mise en cache des jetons.

Le cache de jetons distribués est configuré par MsalDistributedTokenCacheAdapterOptions:

  • Dans le cadre du développement à des fins de débogage, vous pouvez désactiver le cache L1 en définissant DisableL1Cache sur true. Assurez-vous de le remettre à false pour la production.
  • Définissez la taille maximale de votre cache L1CacheOptions.SizeLimit L1 pour empêcher le cache de dépasser la mémoire du serveur. La valeur par défaut est de 500 Mo.
  • Dans le cadre du développement à des fins de débogage, vous pouvez désactiver le chiffrement de jeton au repos en définissant Encrypt sur false, qui est la valeur par défaut. Assurez-vous de le remettre à true pour la production.
  • Définissez l’éviction du jeton du cache avec SlidingExpiration. La valeur par défaut est 1 heure.
  • Pour plus d’informations, notamment des conseils sur le rappel pour les échecs de cache L2 (OnL2CacheFailure) et les écritures asynchrones du cache L2 (EnableAsyncL2Write), consultez MsalDistributedTokenCacheAdapterOptions et sérialisation du cache de jeton : caches de jetons distribués.
builder.Services.AddDistributedMemoryCache();

builder.Services.Configure<MsalDistributedTokenCacheAdapterOptions>(
    options => 
    {
      // The following lines that are commented out reflect
      // default values. We recommend overriding the default
      // value of Encrypt to encrypt tokens at rest.

      //options.DisableL1Cache = false;
      //options.L1CacheOptions.SizeLimit = 500 * 1024 * 1024;
      options.Encrypt = true;
      //options.SlidingExpiration = TimeSpan.FromHours(1);
    });

AddDistributedMemoryCache nécessite une référence au Microsoft.Extensions.Caching.Memory paquet NuGet.

Note

Pour obtenir des conseils sur l'ajout de packages à des applications .NET, consultez les articles figurant sous Installer et gérer des packages dans Flux de travail de la consommation des packages (documentation NuGet). Vérifiez les versions du package sur NuGet.org.

Pour configurer un fournisseur de cache distribué de production, consultez La mise en cache distribuée dans ASP.NET Core.

Warning

Remplacez toujours les caches de jetons distribués en mémoire par un fournisseur de cache de jetons réel lors du déploiement de l’application dans un environnement de production. Si vous ne parvenez pas à adopter un fournisseur de cache de jeton distribué de production, l’application peut subir des performances considérablement dégradées.

Pour plus d’informations, consultez sérialisation du cache de jeton : Caches distribués. Toutefois, les exemples de code présentés ne s’appliquent pas aux applications ASP.NET Core, qui configurent les caches distribués via AddDistributedMemoryCache, et non AddDistributedTokenCache.

Utilisez un trousseau de clés de protection des données partagé en production afin que les instances de l’application sur les serveurs d’une batterie de serveurs Web puissent déchiffrer les jetons lorsque MsalDistributedTokenCacheAdapterOptions.Encrypt est défini sur true.

Note

Pour le développement précoce et les tests locaux sur un seul ordinateur, vous pouvez définir Encryptfalse et configurer un anneau de clés de protection des données partagé ultérieurement :

options.Encrypt = false;

Plus loin dans la période de développement et de test, activez le chiffrement des jetons et adoptez un anneau de clés de protection des données partagé.

L’exemple suivant montre comment utiliser Azure Blob Storage et Azure Key Vault (PersistKeysToAzureBlobStorage/ProtectKeysWithAzureKeyVault) pour le trousseau de clés partagé. Les configurations de service sont des scénarios de cas de base à des fins de démonstration. Avant de déployer des applications de production, familiarisez-vous avec les services Azure et adoptez les meilleures pratiques à l’aide des ensembles de documentation dédiés des services Azure, qui sont liés à la fin de cette section.

Vérifiez la présence des packages suivants dans le projet serveur du Blazor Web App:

Note

Pour obtenir des conseils sur l'ajout de packages à des applications .NET, consultez les articles figurant sous Installer et gérer des packages dans Flux de travail de la consommation des packages (documentation NuGet). Vérifiez les versions du package sur NuGet.org.

Note

Avant de suivre les étapes suivantes, vérifiez que l’application est inscrite auprès de Microsoft Entra.

Le code suivant est généralement implémenté en même temps qu’un fournisseur de cache de jeton distribué de production est implémenté. D’autres options, à la fois dans Azure et en dehors d’Azure, sont disponibles pour gérer les clés de protection des données sur plusieurs instances d’application, mais l’exemple d’application montre comment utiliser les services Azure.

Configurez stockage Blob Azure pour gérer les clés de protection des données. Suivez les instructions des fournisseurs de stockage de clés dans ASP.NET Core.

Configurez Azure Key Vault pour chiffrer les clés de protection des données au repos. Suivez les instructions de Configurer ASP.NET Core Data Protection.

Utilisez le code suivant dans le Program fichier dans lequel les services sont inscrits :

TokenCredential? credential;

if (builder.Environment.IsProduction())
{
    credential = new ManagedIdentityCredential("{MANAGED IDENTITY CLIENT ID}");
}
else
{
    // Local development and testing only
    DefaultAzureCredentialOptions options = new()
    {
        // Specify the tenant ID to use the dev credentials when running the app locally
        // in Visual Studio.
        VisualStudioTenantId = "{TENANT ID}",
        SharedTokenCacheTenantId = "{TENANT ID}"
    };

    credential = new DefaultAzureCredential(options);
}

builder.Services.AddDataProtection()
    .SetApplicationName("BlazorWebAppEntra")
    .PersistKeysToAzureBlobStorage(new Uri("{BLOB URI}"), credential)
    .ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);

Vous pouvez transmettre n’importe quel nom d’application à SetApplicationName. Vérifiez simplement que tous les déploiements d’applications utilisent la même valeur.

{MANAGED IDENTITY CLIENT ID} : ID client Azure Managed Identity (GUID).

{TENANT ID}: ID de locataire.

{BLOB URI}: URI complet vers le fichier de clé. L’URI est généré par Stockage Azure lorsque vous créez le fichier de clé. N’utilisez pas de SAS.

{KEY IDENTIFIER}: identificateur de clé Azure Key Vault utilisé pour le chiffrement de clé. Une stratégie d’accès permet à l’application d’accéder au coffre de clés avec les autorisations Get, Unwrap Key, et Wrap Key. La version de la clé est obtenue à partir de la clé dans Entra ou le portail Azure après sa création. Si vous activez l’autorotation de la clé de coffre de clés, veillez à utiliser un identificateur de clé sans version dans la configuration du coffre de clés de l’application, où aucun GUID de clé n’est placé à la fin de l’identificateur (exemple : https://contoso.vault.azure.net/keys/data-protection).

Note

Dans les environnements hors production, l’exemple précédent utilise DefaultAzureCredential pour simplifier l’authentification lors du développement d’applications qui se déploient sur Azure en combinant les informations d’identification utilisées dans les environnements d’hébergement Azure avec les informations d’identification utilisées dans le développement local. Pour plus d’informations, consultez Authentifier les applications .NET hébergées par Azure auprès des ressources Azure à l’aide d’une identité managée affectée par le système.

Vous pouvez également configurer l’application pour fournir les valeurs des fichiers de paramètres d’application à l’aide du fournisseur de configuration JSON. Ajoutez les éléments suivants au fichier de paramètres de l’application :

"DistributedTokenCache": {
  "DisableL1Cache": false,
  "L1CacheSizeLimit": 524288000,
  "Encrypt": true,
  "SlidingExpirationInHours": 1
},
"DataProtection": {
  "BlobUri": "{BLOB URI}",
  "KeyIdentifier": "{KEY IDENTIFIER}"
}

Section exemple DataProtection :

"DataProtection": {
  "BlobUri": "https://contoso.blob.core.windows.net/data-protection/keys.xml",
  "KeyIdentifier": "https://contoso.vault.azure.net/keys/data-protection"
}

Note

L’identificateur de clé dans l’exemple précédent est sans version. Il n’existe aucune version de clé GUID à la fin de l’identificateur. Cela est particulièrement important si vous choisissez de configurer la rotation automatique des clés pour la clé. Pour plus d’informations, consultez Configurer la rotation automatique des clés de chiffrement dans Azure Key Vault : stratégie de rotation de clé.

Apportez les modifications suivantes dans le fichier Program :

builder.Services.Configure<MsalDistributedTokenCacheAdapterOptions>(
    options =>
    {
+       var config = builder.Configuration.GetSection("DistributedTokenCache");

-       options.DisableL1Cache = false;
+       options.DisableL1Cache = config.GetValue<bool>("DisableL1Cache");

-       options.L1CacheOptions.SizeLimit = 500 * 1024 * 1024;
+       options.L1CacheOptions.SizeLimit = config.GetValue<long>("L1CacheSizeLimit");

-       options.Encrypt = true;
+       options.Encrypt = config.GetValue<bool>("Encrypt");

-       options.SlidingExpiration = TimeSpan.FromHours(1);
+       options.SlidingExpiration = 
+           TimeSpan.FromHours(config.GetValue<int>("SlidingExpirationInHours"));
    });

- builder.Services.AddDataProtection()
-     .SetApplicationName("BlazorWebAppEntra")
-     .PersistKeysToAzureBlobStorage(new Uri("{BLOB URI}"), credential)
-     .ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);

Ajoutez le code suivant dans lequel les services sont configurés dans le Program fichier :

var config = builder.Configuration.GetSection("DataProtection");

builder.Services.AddDataProtection()
    .SetApplicationName("BlazorWebAppEntra")
    .PersistKeysToAzureBlobStorage(
        new Uri(config.GetValue<string>("BlobUri") ??
        throw new Exception("Missing Blob URI")),
        credential)
    .ProtectKeysWithAzureKeyVault(
        new Uri(config.GetValue<string>("KeyIdentifier") ?? 
        throw new Exception("Missing Key Identifier")), 
        credential);

Pour plus d’informations sur l’utilisation d’un anneau de clés et d’un fournisseur de stockage de clés de protection des données partagés, consultez les ressources suivantes :

Préfixe de destination du transmetteur YARP

Le redirecteur YARP du projet serveur Blazor Web App, où le jeton d'accès de l'utilisateur est attaché à l'appel API Web MinimalApiJwt, spécifie un préfixe de destination https://weatherapi. Cette valeur correspond au nom du projet passé à AddProject dans le fichier Program du projet Aspire.AppHost.

Redirecteur dans le projet de serveur Blazor Web App (BlazorWebAppEntra) :

app.MapForwarder("/weather-forecast", "https://weatherapi", transformBuilder =>
{
    ...
}).RequireAuthorization();

Nom de projet correspondant dans le Program fichier du projet Hôte d’application Aspire (Aspire.AppHost) :

var weatherApi = builder.AddProject<Projects.MinimalApiJwt>("weatherapi");

Il n’est pas nécessaire de modifier le préfixe de destination du transpondeur YARP lors du déploiement de Blazor Web App en production. Le package d'API en aval Web Microsoft Identity utilise l'URI de base transmis via la configuration pour effectuer l'appel de l'API web depuis le ServerWeatherForecaster, et non depuis le préfixe de destination du transmetteur YARP. En production, le redirecteur YARP transforme simplement la requête, en ajoutant le jeton d’accès de l’utilisateur.

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

Le composant LogInOrOut (Layout/LogInOrOut.razor) définit un champ masqué pour l’URL de retour (ReturnUrl) sur l’URL actuelle (currentURL). Lorsque l’utilisateur se déconnecte de l’application, le fournisseur d’identité renvoie l’utilisateur à la page à partir de laquelle il s’est déconnecté. Si l’utilisateur se déconnecte d’une page sécurisée, il est retourné à la même page sécurisée et renvoyé par le biais du processus d’authentification. Ce flux d’authentification est raisonnable lorsque les utilisateurs doivent modifier régulièrement des comptes.

Vous pouvez également utiliser le composant LogInOrOut suivant, qui ne fournit pas d’URL de retour lors de la déconnexion.

Layout/LogInOrOut.razor :

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout
                </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>

Sécurité des données météorologiques

Pour plus d’informations sur la façon dont cette application sécurise ses données météorologiques, consultez Sécurisation des données dans Blazor Web Apps avec un rendu automatique interactif.

Troubleshoot

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 de l’authentification côté client de la documentation sur la journalisation ASP.NET Core Blazor avec le sélecteur de version de l’article défini sur ASP.NET Core dans .NET 7 ou version ultérieure.

Erreurs courantes

  • Le débogueur s'interrompt sur une exception lors de la déconnexion avec Microsoft Entra ID Externe

    L'exception suivante arrête le débogueur de Visual Studio lors de la déconnexion avec Microsoft Entra External ID :

    Uncaught TypeError TypeError: Failed to execute 'postMessage' on 'Window': The provided value cannot be converted to a sequence.

    Le débogueur de Visual Studio est interrompu par une exception JavaScript lors de la déconnexion.

    L’exception est levée à partir du code JavaScript Entra. Il ne s’agit donc pas d’un problème avec ASP.NET Core. L’exception n’a pas d’impact sur les fonctionnalités d’application en production. L’exception peut donc être ignorée pendant les tests de développement locaux.

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

    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'enregistrement de l'application 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 :

    • Analyser les journaux d’application.

    • Examinez le trafic réseau entre l’application cliente et l'application serveur ou l'adresse IP à l’aide des outils de développement du navigateur. Bien souvent, après qu’une requête a été faite, un message d’erreur précis ou donnant un indice sur la cause du problème est renvoyé au client par le fournisseur d’identité ou l’application serveur. Vous trouverez des conseils d’aide sur les outils de développement dans les articles suivants :

    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 dans le produit que des attaquants peuvent exploiter, consultez Signaler des problèmes de sécurité et des bugs (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 connexion depuis 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 au fil des mises à jour des applications, 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 des utilisateurs
  • Cookies d’application
  • Données de site mises en cache et stockées

Il existe une approche qui permet d’empêcher les cookies 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 de développement logiciel (SDK) .NET 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 :

  1. 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.
  2. Supprimez les dossiers bin et obj du projet.
  3. Restaurez et reconstruisez le projet.
  4. Supprimez tous les fichiers du dossier de déploiement sur le serveur avant de redéployer l’application.

Note

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.

Démarrer la solution à partir du projet approprié

Blazor Web Apps :

  • Pour l’un des exemples de modèle Backend-for-Frontend (BFF), démarrez la solution à partir du Aspire/Aspire.AppHost projet.
  • Pour l’un des exemples de modèle non BFF, démarrez la solution à partir du projet de serveur.

Blazor Server :

Démarrez la solution à partir du projet 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.Any())
{
    <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