Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Note
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 10 de cet article.
Cet article explique comment sécuriser une Blazor Web App avec OpenID Connect (OIDC) en utilisant un exemple d’application du référentiel GitHub dotnet/blazor-samples (.NET 8 ou ultérieur) (comment télécharger).
Pour Microsoft Entra ID ou Azure AD B2C, vous pouvez utiliser AddMicrosoftIdentityWebApp à partir de Microsoft Identity Web (Microsoft.Identity.Web package NuGet, documentation de l’API), qui ajoute à la fois les gestionnaires OIDC et Cookie d’authentification avec les valeurs par défaut appropriées. L’exemple d’application et les conseils de cet article n’utilisent pas Microsoft Identity Web. L’aide montre comment configurer manuellement le gestionnaire OIDC pour n’importe quel fournisseur OIDC. Pour plus d’informations sur l’implémentation de Microsoft Identity Web, consultez Sécuriser un ASP.NET Core Blazor Web App avec Microsoft Entra ID.
Cette version de l'article couvre la mise en œuvre de l'OIDC sans adopter le modèle Backend for Frontend (BFF) avec une application qui adopte le rendu global Interactive Auto (serveur et projets .Client). 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 adoptée :
- 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.
- Un projet d’API web distinct illustre un appel d’API web sécurisé pour les données météorologiques.
Pour une expérience alternative utilisant Microsoft Authentication Library for .NET, Microsoft Identity Web, et Microsoft Entra ID, veuillez consulter la section Sécuriser un ASP.NET Core Blazor Web App avec Microsoft Entra ID.
Exemple de solution
L’exemple d’application se compose des projets suivants :
-
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 la Blazor Web App. -
MinimalApiJwt: API web back-end avec un point de terminaison Minimal API 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 BlazorWebAppOidc dossier pour .NET 8 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)
Exemples de fonctionnalités de solution :
Actualisation automatique des jetons non interactifs avec l’aide d’un actualiseur cookie personnalisé (
CookieOidcRefresher.cs).Les données météorologiques sont gérées par un point de terminaison d’API minimal (
/weather-forecast) dans leProgramfichier (Program.cs) duMinimalApiJwtprojet. Le point de terminaison demande une autorisation en appelant RequireAuthorization. Pour les contrôleurs que vous ajoutez au projet, ajoutez l’attribut[Authorize]au contrôleur ou à l’action. Pour plus d'informations sur l'autorisation requise dans l'application via une stratégie d'autorisation et la désactivation de l'autorisation à un sous-ensemble de points de terminaison publics, consultez le guide OIDC de Razor Pages.L’application appelle en toute sécurité une API web pour les données météorologiques :
- Lors du rendu du composant
Weathersur le serveur, le composant utilise le serveurServerWeatherForecasterpour obtenir des données météorologiques à partir de l’API web dans le projetMinimalApiJwtà l’aide d’un DelegatingHandler (TokenHandler) qui attache le jeton d’accès de HttpContext à la requête. - Lorsque le composant est rendu sur le client, le composant utilise l’implémentation
ClientWeatherForecasterdu service, qui utilise un préconfiguré HttpClient (dans le fichier duProgramprojet client) pour effectuer l’appel d’API web à partir duServerWeatherForecasterprojet de serveur.
- Lors du rendu du composant
- 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 utilise AddAuthenticationStateDeserialization pour désérialiser et utiliser l’état d’authentification fourni par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
- La classe
PersistingAuthenticationStateProvider(PersistingAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté serveur qui utilise PersistentComponentState pour transmettre l’état de l’authentification au client, qui est ensuite fixé pour la durée de vie de l’application WebAssembly.
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.
Terminologie et conseils du fournisseur OIDC
Bien que vous n’ayez pas besoin d’adopter Microsoft Entra (ME-ID) en tant que fournisseur OIDC pour utiliser l’exemple d’application et les conseils de cet article, cet article décrit les paramètres de ME-ID à l’aide de noms trouvés dans la documentation Microsoft et les portails Azure/Entra. Les paramètres OIDC ont des noms similaires entre les fournisseurs OIDC. Lors de l’utilisation d’un fournisseur OIDC tiers, utilisez la documentation du fournisseur conjointement avec les instructions fournies dans cet article pour les inscriptions d’API web et d’application.
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 BlazorWebAppOidc 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.
Pour obtenir des conseils sur l’inscription d’api web et d’application, consultez Inscrire une application dans l’ID Microsoft Entra.
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 (BlazorWebAppOidc/BlazorWebApOidc.Client) avec une configuration de la plateforme Web et un URI de redirection de (un port n’est pas obligatoire). L’ID d’abonné 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, permettent de configurer l’application dans son fichier Program. 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.
Établir le secret du client
Cette section s’applique uniquement au projet serveur du Blazor Web App (BlazorWebAppOidc projet).
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.
Pour les tests de développement locaux, utilisez l’outil Gestionnaire de secrets pour stocker la Blazor clé secrète client du projet de serveur sous la clé Authentication:Schemes:MicrosoftOidc:ClientSecretde configuration.
Le Blazor projet de serveur n’a pas été initialisé 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 en utilisant la commande cd vers le 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 le secret du client. L'espace réservé {SECRET} est le secret du client obtenu lors 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.
MinimalApiJwt projet
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.
Le projet inclut des packages et une configuration pour produire des documents OpenAPI et l’interface utilisateur Swagger dans l’environnement de développement. Pour plus d’informations, consultez Utiliser les documents OpenAPI générés.
Le projet crée un point de terminaison d’API minimal pour les données météorologiques :
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();
Configurez le projet dans le JwtBearerOptions de l’appel AddJwtBearer dans le fichier Program du projet.
Authority définit l'autorité pour passer des appels OIDC. Nous vous recommandons d’utiliser une inscription d’application distincte pour le MinimalApiJwt projet. L’autorité correspond à l’émetteur (iss) du jeton JWT renvoyé par le fournisseur d’identité.
jwtOptions.Authority = "{AUTHORITY}";
Le format de l’autorité dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee.
Exemple d’autorité d’abonné ME-ID :
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee";
Exemple d’autorité d’abonné AAD B2C :
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Le Audience définit l’audience de tout jeton OIDC reçu.
jwtOptions.Audience = "{APP ID URI}";
Note
Lorsque vous utilisez Microsoft Entra ID, faites correspondre la valeur au chemin de l'URI de l'ID de l'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.
Le format de l’audience dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de contoso et un ID client de 11112222-bbbb-3333-cccc-4444dddd5555.
exemple d’URI d’ID d’application client ME-ID :
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Exemple d’URI d’ID d’application client AAD B2C :
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Blazor Web App projet serveur (BlazorWebAppOidc)
Le projet BlazorWebAppOidc est le projet côté serveur de l’Blazor Web App.
A DelegatingHandler (TokenHandler) gère l’attachement du jeton d’accès d’un utilisateur aux requêtes sortantes. Le gestionnaire de jetons s’exécute uniquement pendant le rendu côté serveur statique (SSR statique), l’utilisation HttpContext est donc sécurisée dans ce scénario. Pour plus d’informations, consultez IHttpContextAccessor/HttpContext dans les applications ASP.NET Core Blazor et les scénarios de sécurité supplémentaires côté Blazor Web App serveur ASP.NET Core.
TokenHandler.cs :
public class TokenHandler(IHttpContextAccessor httpContextAccessor) :
DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
if (httpContextAccessor.HttpContext is null)
{
throw new Exception("HttpContext not available");
}
var accessToken = await httpContextAccessor.HttpContext
.GetTokenAsync("access_token");
request.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", accessToken);
return await base.SendAsync(request, cancellationToken);
}
}
Dans le fichier Program du projet, le gestionnaire de jetons (TokenHandler) est inscrit en tant que service et spécifié comme gestionnaire de messages avec AddHttpMessageHandler pour effectuer des requêtes sécurisées à l’API web du backend MinimalApiJwt à l’aide d’un client HTTP nommé («ExternalApi »).
builder.Services.AddScoped<TokenHandler>();
builder.Services.AddHttpClient("ExternalApi",
client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ??
throw new Exception("Missing base address!")))
.AddHttpMessageHandler<TokenHandler>();
Dans le fichier du appsettings.json projet, configurez l’URI de l’API externe :
"ExternalApiUri": "{BASE ADDRESS}"
Example:
"ExternalApiUri": "https://localhost:7277"
La configuration OpenIdConnectOptions suivante se trouve dans le fichier Program du projet sur l’appel à AddOpenIdConnect :
PushedAuthorizationBehavior: Contrôle la prise en charge des demandes d’autorisation push (PAR). Par défaut, le paramètre est d'utiliser PAR si le document de découverte du fournisseur d'identité (généralement disponible à l'adresse .well-known/openid-configuration) annonce la prise en charge de PAR. Si vous souhaitez que l'application soit prise en charge par PAR, vous pouvez attribuer une valeur PushedAuthorizationBehavior.Require. PAR n’est pas pris en charge par Microsoft Entra, et il n’y a pas de plans pour que Entra ne le supporte jamais à l’avenir.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme : Définit le schéma d'authentification correspondant à l'intergiciel responsable de la persistance de l'identité de l'utilisateur après une authentification réussie. Le gestionnaire OIDC doit utiliser un schéma de connexion capable de conserver les informations d’identification de l’utilisateur entre les requêtes. La ligne suivante est présente seulement à des fins de démonstration. Si elle est omise, DefaultSignInScheme est utilisé comme valeur de secours.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Étendues pour openid et profile (Scope) (Facultatif) : les étendues openid et profile sont également configurées par défaut, car elles sont nécessaires pour que le gestionnaire OIDC fonctionne, mais il peut être nécessaire de les ajouter à nouveau si des étendues sont incluses dans la configuration de Authentication:Schemes:MicrosoftOidc:Scope. Pour obtenir une aide générale sur la configuration, consultez Configuration dans ASP.NET Core et Configuration d’ASP.NET Core Blazor.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
SaveTokens : définit si les jetons d’accès et d’actualisation doivent être stockés dans les AuthenticationProperties après une autorisation réussie. Cette propriété est définie sur true afin que le jeton d'actualisation soit stocké pour l'actualisation non interactive des jetons.
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);
Authority et ClientId : définit l’autorité et l’ID client pour les appels OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
L'exemple suivant utilise un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee et un ID client de 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";
Pour les applications multi-locataires, l’autorité « commune » doit être utilisée. 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. 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'identité pour plus d'informations.
Note
MapInboundClaims doit être configuré à false pour la plupart des fournisseurs OIDC, ce qui empêche le renommage des réclamations.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuration du chemin d'accès : Les chemins d'accès doivent être identiques à l'URI de redirection (chemin de rappel de connexion) et aux chemins de redirection après déconnexion (chemin de rappel après déconnexion) configurés lors de l'enregistrement 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 de la requête dans le chemin de base de l'application où l'agent utilisateur est renvoyé.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signin-oidc
Note
Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs de l'OIDC exigent le port correct.
SignedOutCallbackPath (clé de configuration : «SignedOutCallbackPath») : le chemin de requête à l'intérieur du chemin de base de l'application, intercepté par le gestionnaire OIDC, où l'agent utilisateur est d'abord redirigé après s'être déconnecté du fournisseur d'identité. L'exemple d'application ne définit pas de valeur pour le chemin d'accès car la valeur par défaut de « /signout-callback-oidc » est utilisée. Après avoir intercepté la requête, le gestionnaire OIDC redirige vers le SignedOutRedirectUri ou RedirectUri, si spécifié.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signout-callback-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez le chemin d'accès dans les entrées Redirect URI de la configuration de la plateforme Web dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le port correct. Si vous n’ajoutez pas l’URI de chemin de retour après déconnexion à l’enregistrement de l’application dans Entra, Entra refuse de rediriger l’utilisateur à l’application et lui demande simplement de fermer la fenêtre du navigateur.
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 l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost/signout-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez l’URL de Front-channel logout) dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le 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 d'émetteur par défaut, mais nous devons prendre en compte l’émetteur configuré avec l’ID du 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 « commun » :
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Projet client Blazor Web App (BlazorWebAppOidc.Client)
Le projet BlazorWebAppOidc.Client est le projet côté client de l’Blazor Web App.
Le client utilise AddAuthenticationStateDeserialization pour désérialiser et utiliser l’état d’authentification fourni par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
La classe PersistentAuthenticationStateProvider (PersistentAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté client qui détermine l’état d’authentification de l’utilisateur en recherchant les données conservées dans la page quand elle a été rendue sur le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
Si l’utilisateur doit se connecter ou se déconnecter, un rechargement complet de la page est nécessaire.
L’exemple d’application fournit un nom d’utilisateur et un e-mail seulement à des fins d’affichage.
Pour Microsoft Entra ID ou Azure AD B2C, vous pouvez utiliser AddMicrosoftIdentityWebApp à partir de Microsoft Identity Web (Microsoft.Identity.Web package NuGet, documentation de l’API), qui ajoute à la fois les gestionnaires OIDC et Cookie d’authentification avec les valeurs par défaut appropriées. L’exemple d’application et les conseils de cet article n’utilisent pas Microsoft Identity Web. L’aide montre comment configurer manuellement le gestionnaire OIDC pour n’importe quel fournisseur OIDC. Pour plus d’informations sur l’implémentation de Microsoft Identity Web, consultez Sécuriser un ASP.NET Core Blazor Web App avec Microsoft Entra ID.
Cette version de l'article couvre la mise en œuvre de l'OIDC sans adopter le modèle Backend for Frontend (BFF) avec une application qui adopte le mode de rendu Serveur interactif global (projet unique). 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 avec le rendu global interactif automatique.
La spécification suivante est adoptée :
- Le composant Blazor Web App utilise le mode de rendu Serveur avec une interactivité globale.
- 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.
- Un projet d’API web distinct illustre un appel d’API web sécurisé pour les données météorologiques.
Pour une expérience alternative utilisant Microsoft Authentication Library for .NET, Microsoft Identity Web, et Microsoft Entra ID, veuillez consulter la section Sécuriser un ASP.NET Core Blazor Web App avec Microsoft Entra ID.
Exemple de solution
L’exemple d’application se compose des projets suivants :
-
BlazorWebAppOidcServer: Blazor Web App projet côté serveur (rendu global interactive du serveur). -
MinimalApiJwt: API web back-end avec un point de terminaison Minimal API 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 BlazorWebAppOidcServer dossier pour .NET 8 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 BlazorWebAppOidcServer 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 (BlazorWebAppOidcServer) avec une configuration de plateforme Web et un Redirect URI de https://localhost/signin-oidc (un port n’est pas obligatoire). L’ID d’abonné 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, permettent de configurer l’application dans son fichier Program. 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.
Établir le secret du client
Cette section s’applique uniquement au projet serveur du Blazor Web App (BlazorWebAppOidcServer projet).
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.
Pour les tests de développement locaux, utilisez l’outil Gestionnaire de secrets pour stocker la Blazor clé secrète client du projet de serveur sous la clé Authentication:Schemes:MicrosoftOidc:ClientSecretde configuration.
Le Blazor projet de serveur n’a pas été initialisé 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 en utilisant la commande cd vers le répertoire du projet de serveur. La commande établit un identifiant de secrets utilisateur (<UserSecretsId> dans le fichier de projet de l'application) :
dotnet user-secrets init
Exécutez la commande suivante pour définir le secret du client. L'espace réservé {SECRET} est le secret du client obtenu lors 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 de la souris sur le projet dans l'Explorateur de solutions et en sélectionnant Gérer les secrets utilisateur.
MinimalApiJwt projet
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.
Le projet inclut des packages et une configuration pour produire des documents OpenAPI et l’interface utilisateur Swagger dans l’environnement de développement. Pour plus d’informations, consultez Utiliser les documents OpenAPI générés.
Le projet crée un point de terminaison d’API minimal pour les données météorologiques :
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();
Configurez le projet dans le JwtBearerOptions de l’appel AddJwtBearer dans le fichier Program du projet.
Authority définit l'autorité pour passer des appels OIDC. Nous vous recommandons d’utiliser une inscription d’application distincte pour le MinimalApiJwt projet. L’autorité correspond à l’émetteur (iss) du jeton JWT renvoyé par le fournisseur d’identité.
jwtOptions.Authority = "{AUTHORITY}";
Le format de l’autorité dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee.
Exemple d’autorité d’abonné ME-ID :
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee";
Exemple d’autorité d’abonné AAD B2C :
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Le Audience définit l’audience de tout jeton OIDC reçu.
jwtOptions.Audience = "{APP ID URI}";
Note
Lorsque vous utilisez Microsoft Entra ID, faites correspondre la valeur au chemin de l'URI de l'ID de l'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.
Le format de l’audience dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de contoso et un ID client de 11112222-bbbb-3333-cccc-4444dddd5555.
exemple d’URI d’ID d’application client ME-ID :
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Exemple d’URI d’ID d’application client AAD B2C :
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
BlazorWebAppOidcServer projet
L’actualisation automatique des jetons non interactifs est gérée par un actualiseur personnalisé cookie (CookieOidcRefresher.cs).
A DelegatingHandler (TokenHandler) gère l’attachement du jeton d’accès d’un utilisateur aux requêtes sortantes. Le gestionnaire de jetons s’exécute uniquement pendant le rendu côté serveur statique (SSR statique), l’utilisation HttpContext est donc sécurisée dans ce scénario. Pour plus d’informations, consultez IHttpContextAccessor/HttpContext dans les applications ASP.NET Core Blazor et les scénarios de sécurité supplémentaires côté Blazor Web App serveur ASP.NET Core.
TokenHandler.cs :
public class TokenHandler(IHttpContextAccessor httpContextAccessor) :
DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
if (httpContextAccessor.HttpContext is null)
{
throw new Exception("HttpContext not available");
}
var accessToken = await httpContextAccessor.HttpContext
.GetTokenAsync("access_token");
request.Headers.Authorization =
new AuthenticationHeaderValue("Bearer", accessToken);
return await base.SendAsync(request, cancellationToken);
}
}
Dans le fichier Program du projet, le gestionnaire de jetons (TokenHandler) est inscrit en tant que service et spécifié comme gestionnaire de messages avec AddHttpMessageHandler pour effectuer des requêtes sécurisées à l’API web du backend MinimalApiJwt à l’aide d’un client HTTP nommé («ExternalApi »).
builder.Services.AddScoped<TokenHandler>();
builder.Services.AddHttpClient("ExternalApi",
client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ??
throw new Exception("Missing base address!")))
.AddHttpMessageHandler<TokenHandler>();
Le composant Weather utilise l'attribut [Authorize] pour empêcher tout accès non autorisé. Pour plus d'informations sur l'autorisation requise dans l'application via une stratégie d'autorisation et la désactivation de l'autorisation à un sous-ensemble de points de terminaison publics, consultez le guide OIDC de Razor Pages.
Le ExternalApi client HTTP est utilisé pour effectuer une demande de données météorologiques à l’API web sécurisée. Dans l’événement de cycle de vie OnInitializedAsync de Weather.razor :
using var request = new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
var client = ClientFactory.CreateClient("ExternalApi");
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
forecasts = await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
throw new IOException("No weather forecast!");
Dans le fichier du appsettings.json projet, configurez l’URI de l’API externe :
"ExternalApiUri": "{BASE ADDRESS}"
Example:
"ExternalApiUri": "https://localhost:7277"
La configuration OpenIdConnectOptions suivante se trouve dans le fichier Program du projet sur l’appel à AddOpenIdConnect :
PushedAuthorizationBehavior: Contrôle la prise en charge des demandes d’autorisation push (PAR). Par défaut, le paramètre est d'utiliser PAR si le document de découverte du fournisseur d'identité (généralement disponible à l'adresse .well-known/openid-configuration) annonce la prise en charge de PAR. Si vous souhaitez que l'application soit prise en charge par PAR, vous pouvez attribuer une valeur PushedAuthorizationBehavior.Require. PAR n’est pas pris en charge par Microsoft Entra, et il n’y a pas de plans pour que Entra ne le supporte jamais à l’avenir.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme : Définit le schéma d'authentification correspondant à l'intergiciel responsable de la persistance de l'identité de l'utilisateur après une authentification réussie. Le gestionnaire OIDC doit utiliser un schéma de connexion capable de conserver les informations d’identification de l’utilisateur entre les requêtes. La ligne suivante est présente seulement à des fins de démonstration. Si elle est omise, DefaultSignInScheme est utilisé comme valeur de secours.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Étendues pour openid et profile (Scope) (Facultatif) : les étendues openid et profile sont également configurées par défaut, car elles sont nécessaires pour que le gestionnaire OIDC fonctionne, mais il peut être nécessaire de les ajouter à nouveau si des étendues sont incluses dans la configuration de Authentication:Schemes:MicrosoftOidc:Scope. Pour obtenir une aide générale sur la configuration, consultez Configuration dans ASP.NET Core et Configuration d’ASP.NET Core Blazor.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
Configurez l’étendue Weather.Get d’accès à l’API web externe de données météo. L’exemple suivant est basé sur l’utilisation de l’ID Entra dans un domaine de locataire ME-ID. Dans l’exemple suivant, l’espace réservé {APP ID URI} se trouve dans le portail Entra ou Azure où l’API web est disponible. Pour tout autre fournisseur d’identité, utilisez l’étendue appropriée.
oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");
Le format de l’étendue dépend du type d’abonné utilisé. Dans les exemples suivants, le domaine du locataire est contoso.onmicrosoft.com, et l’ID client est 11112222-bbbb-3333-cccc-4444dddd5555.
exemple d’URI d’ID d’application client ME-ID :
oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Exemple d’URI d’ID d’application client AAD B2C :
oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
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 sur true afin que le jeton d'actualisation soit stocké pour l'actualisation non interactive des jetons.
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);
Authority et ClientId : définit l’autorité et l’ID client pour les appels OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
L'exemple suivant utilise un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee et un ID client de 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";
Pour les applications multi-locataires, l’autorité « commune » doit être utilisée. 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. 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'identité pour plus d'informations.
Note
MapInboundClaims doit être configuré à false pour la plupart des fournisseurs OIDC, ce qui empêche le renommage des réclamations.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuration du chemin d'accès : Les chemins d'accès doivent être identiques à l'URI de redirection (chemin de rappel de connexion) et aux chemins de redirection après déconnexion (chemin de rappel après déconnexion) configurés lors de l'enregistrement 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 de la requête dans le chemin de base de l'application où l'agent utilisateur est renvoyé.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signin-oidc
Note
Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs de l'OIDC exigent le port correct.
SignedOutCallbackPath (clé de configuration : «SignedOutCallbackPath») : le chemin de requête à l'intérieur du chemin de base de l'application, intercepté par le gestionnaire OIDC, où l'agent utilisateur est d'abord redirigé après s'être déconnecté du fournisseur d'identité. L'exemple d'application ne définit pas de valeur pour le chemin d'accès car la valeur par défaut de « /signout-callback-oidc » est utilisée. Après avoir intercepté la requête, le gestionnaire OIDC redirige vers le SignedOutRedirectUri ou RedirectUri, si spécifié.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signout-callback-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez le chemin d'accès dans les entrées Redirect URI de la configuration de la plateforme Web dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le port correct. Si vous n’ajoutez pas l’URI de chemin de retour après déconnexion à l’enregistrement de l’application dans Entra, Entra refuse de rediriger l’utilisateur à l’application et lui demande simplement de fermer la fenêtre du navigateur.
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 l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost/signout-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez l’URL de Front-channel logout) dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le 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 d'émetteur par défaut, mais nous devons prendre en compte l’émetteur configuré avec l’ID du 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 « commun » :
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Pour Microsoft Entra ID ou Azure AD B2C, vous pouvez utiliser AddMicrosoftIdentityWebApp à partir de Microsoft Identity Web (Microsoft.Identity.Web package NuGet, documentation de l’API), qui ajoute à la fois les gestionnaires OIDC et Cookie d’authentification avec les valeurs par défaut appropriées. L’exemple d’application et les conseils de cet article n’utilisent pas Microsoft Identity Web. L’aide montre comment configurer manuellement le gestionnaire OIDC pour n’importe quel fournisseur OIDC. Pour plus d’informations sur l’implémentation de Microsoft Identity Web, consultez Sécuriser un ASP.NET Core Blazor Web App avec Microsoft Entra ID.
Cette version de l’article traite de l’implémentation d’OIDC avec le modèle BFF (Backend for Frontend). Si la spécification de l’application n’appelle pas l’adoption du modèle BFF, remplacez le sélecteur de version d'article par le modèle non BFF (rendu automatique interactif) ou modèle non BFF (rendu interactif du serveur).
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 d’application 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. -
BlazorWebAppOidc: Projet côté serveur du 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 leaccess_tokenstocké dans le cookie d’authentification. -
BlazorWebAppOidc.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 BlazorWebAppOidcBff dossier pour .NET 8 ou version ultérieure.
Affichez ou téléchargez l’exemple de code (procédure de téléchargement)
L’Blazor Web App utilise le mode de rendu automatique avec interactivité globale.
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 utilise AddAuthenticationStateDeserialization pour désérialiser et utiliser l’état d’authentification fourni par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
La classe PersistingAuthenticationStateProvider (PersistingAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté serveur qui utilise PersistentComponentState pour transmettre l’état de l’authentification au client, qui est ensuite fixé pour la durée de vie de l’application WebAssembly.
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 avec l’aide d’un actualiseur cookie personnalisé (CookieOidcRefresher.cs).
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.
L’API web back-end (MinimalApiJwt) valide les jetons JWT enregistrés par le Blazor Web App dans le cookie de connexion à l’aide de l’authentification par porteur JWT.
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.
MapForwarder dans le fichier Program du projet serveur ajoute le transfert direct des requêtes HTTP qui correspondent au modèle spécifié vers une destination spécifique, en utilisant la configuration par défaut pour la requête sortante, des transformations personnalisées et le client HTTP par défaut.
- Lors du rendu du composant
Weathersur le serveur, le composant utilise la classeServerWeatherForecasterpour proxyer la requête de données météorologiques avec le jeton d'accès de l'utilisateur. IHttpContextAccessor.HttpContext détermine si un HttpContext est disponible pour être utilisé par la méthode XXXGetWeatherForecastAsyncPour plus d’informations, consultez les composants ASP.NET Core Razor. - Lorsque le composant est rendu sur le client, le composant utilise l’implémentation du service
ClientWeatherForecaster, qui utilise un HttpClient préconfiguré (dans le fichierProgramdu projet client) pour effectuer un appel d’API web au projet de serveur. Un point de terminaison d’API minimal (/weather-forecast) défini dans le fichierProgramdu projet de serveur transforme la requête avec le jeton d’accès de l’utilisateur pour obtenir les données météo.
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.
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 BlazorWebAppOidc 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 (BlazorWebAppOidc/BlazorWebApOidc.Client) avec une configuration de la plateforme Web et un URI de redirection de (un port n’est pas obligatoire). L’ID d’abonné 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, permettent de configurer l’application dans son fichier Program. 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.
Établir le secret du client
Cette section s’applique uniquement au projet serveur du Blazor Web App (BlazorWebAppOidc projet).
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.
Pour les tests de développement locaux, utilisez l’outil Gestionnaire de secrets pour stocker la Blazor clé secrète client du projet de serveur sous la clé Authentication:Schemes:MicrosoftOidc:ClientSecretde configuration.
Le Blazor projet de serveur n’a pas été initialisé 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 en utilisant la commande cd vers le 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 le secret du client. L'espace réservé {SECRET} est le secret du client obtenu lors 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.
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).
MinimalApiJwt projet
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.
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.
Le projet inclut des packages et une configuration pour produire des documents OpenAPI et l’interface utilisateur Swagger dans l’environnement de développement. Pour plus d’informations, consultez Utiliser les documents OpenAPI générés.
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.
Configurez le projet dans le JwtBearerOptions de l’appel AddJwtBearer dans le fichier Program du projet.
Authority définit l'autorité pour passer des appels OIDC. Nous vous recommandons d’utiliser une inscription d’application distincte pour le MinimalApiJwt projet. L’autorité correspond à l’émetteur (iss) du jeton JWT renvoyé par le fournisseur d’identité.
jwtOptions.Authority = "{AUTHORITY}";
Le format de l’autorité dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee.
Exemple d’autorité d’abonné ME-ID :
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee";
Exemple d’autorité d’abonné AAD B2C :
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Le Audience définit l’audience de tout jeton OIDC reçu.
jwtOptions.Audience = "{APP ID URI}";
Note
Lorsque vous utilisez Microsoft Entra ID, faites correspondre la valeur au chemin de l'URI de l'ID de l'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.
Le format de l’audience dépend du type d’abonné utilisé. Les exemples suivants pour Microsoft Entra ID utilisent un ID de locataire de contoso et un ID client de 11112222-bbbb-3333-cccc-4444dddd5555.
exemple d’URI d’ID d’application client ME-ID :
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Exemple d’URI d’ID d’application client AAD B2C :
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Projet côté serveur Blazor Web App (BlazorWebAppOidc)
Cette section explique comment configurer le projet côté Blazor serveur.
La configuration OpenIdConnectOptions suivante se trouve dans le fichier Program du projet sur l’appel à AddOpenIdConnect.
PushedAuthorizationBehavior: Contrôle la prise en charge des demandes d’autorisation push (PAR). Par défaut, le paramètre est d'utiliser PAR si le document de découverte du fournisseur d'identité (généralement disponible à l'adresse .well-known/openid-configuration) annonce la prise en charge de PAR. Si vous souhaitez que l'application soit prise en charge par PAR, vous pouvez attribuer une valeur PushedAuthorizationBehavior.Require. PAR n’est pas pris en charge par Microsoft Entra, et il n’y a pas de plans pour que Entra ne le supporte jamais à l’avenir.
oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;
SignInScheme : Définit le schéma d'authentification correspondant à l'intergiciel responsable de la persistance de l'identité de l'utilisateur après une authentification réussie. Le gestionnaire OIDC doit utiliser un schéma de connexion capable de conserver les informations d’identification de l’utilisateur entre les requêtes. La ligne suivante est présente seulement à des fins de démonstration. Si elle est omise, DefaultSignInScheme est utilisé comme valeur de secours.
oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
Étendues pour openid et profile (Scope) (Facultatif) : les étendues openid et profile sont également configurées par défaut, car elles sont nécessaires pour que le gestionnaire OIDC fonctionne, mais il peut être nécessaire de les ajouter à nouveau si des étendues sont incluses dans la configuration de Authentication:Schemes:MicrosoftOidc:Scope. Pour obtenir une aide générale sur la configuration, consultez Configuration dans ASP.NET Core et Configuration d’ASP.NET Core Blazor.
oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
SaveTokens : définit si les jetons d’accès et d’actualisation doivent être stockés dans les AuthenticationProperties après une autorisation réussie. La valeur est définie sur true pour authentifier les requêtes de données météorologiques depuis le projet d’API web back-end (MinimalApiJwt).
oidcOptions.SaveTokens = true;
Étendue de l’accès hors connexion (Scope) : l’étendue offline_access est nécessaire pour le jeton d’actualisation.
oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
Étendues pour obtenir des données météorologiques à partir de l’API web (Scope) : configurez l’étendue Weather.Get pour accéder à l’API web externe pour les données météorologiques. Dans l’exemple suivant, l’espace réservé {APP ID URI} se trouve dans le portail Entra ou Azure où l’API web est disponible. Pour tout autre fournisseur d’identité, utilisez l’étendue appropriée.
oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");
Le format de l’étendue dépend du type d’abonné utilisé. Dans les exemples suivants, le domaine du locataire est contoso.onmicrosoft.com, et l’ID client est 11112222-bbbb-3333-cccc-4444dddd5555.
exemple d’URI d’ID d’application client ME-ID :
oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Exemple d’URI d’ID d’application client AAD B2C :
oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");
Authority et ClientId : définit l’autorité et l’ID client pour les appels OIDC.
oidcOptions.Authority = "{AUTHORITY}";
oidcOptions.ClientId = "{CLIENT ID}";
L'exemple suivant utilise un ID de locataire de aaaabbbb-0000-cccc-1111-dddd2222eeee et un ID client de 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";
Pour les applications multi-locataires, l’autorité « commune » doit être utilisée. 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. 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'identité pour plus d'informations.
Note
MapInboundClaims doit être configuré à false pour la plupart des fournisseurs OIDC, ce qui empêche le renommage des réclamations.
oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = "name";
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Configuration du chemin d'accès : Les chemins d'accès doivent être identiques à l'URI de redirection (chemin de rappel de connexion) et aux chemins de redirection après déconnexion (chemin de rappel après déconnexion) configurés lors de l'enregistrement 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.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signin-oidc
Note
Un port n’est pas requis pour les adresses localhost lors de l’utilisation de Microsoft Entra ID. La plupart des autres fournisseurs de l'OIDC exigent le port correct.
SignedOutCallbackPath (clé de configuration : «SignedOutCallbackPath») : le chemin de requête à l'intérieur du chemin de base de l'application, intercepté par le gestionnaire OIDC, où l'agent utilisateur est d'abord redirigé après s'être déconnecté du fournisseur d'identité. L'exemple d'application ne définit pas de valeur pour le chemin d'accès car la valeur par défaut de « /signout-callback-oidc » est utilisée. Après avoir intercepté la requête, le gestionnaire OIDC redirige vers le SignedOutRedirectUri ou RedirectUri, si spécifié.
Configurez le chemin de rappel signé dans l'enregistrement du fournisseur OIDC de l'application. Dans l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost:{PORT}/signout-callback-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez le chemin d'accès dans les entrées Redirect URI de la configuration de la plateforme Web dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le port correct. Si vous n’ajoutez pas l’URI de chemin de retour après déconnexion à l’enregistrement de l’application dans Entra, Entra refuse de rediriger l’utilisateur à l’application et lui demande simplement de fermer la fenêtre du navigateur.
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 l'exemple suivant, le paramètre de substitution {PORT} est le port de l'application :
https://localhost/signout-oidc
Note
Lorsque vous utilisez Microsoft Entra ID, définissez l’URL de Front-channel logout) dans le portail Entra ou Azure. Un port n'est pas nécessaire pour les adresses localhost lorsque vous utilisez Entra. La plupart des autres fournisseurs de l'OIDC exigent le 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 d'émetteur par défaut, mais nous devons prendre en compte l’émetteur configuré avec l’ID du 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 « commun » :
var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
Projet Blazor Web App côté client (BlazorWebAppOidc.Client)
Le projet BlazorWebAppOidc.Client est le projet côté client de l’Blazor Web App.
Le client utilise AddAuthenticationStateDeserialization pour désérialiser et utiliser l’état d’authentification fourni par le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
La classe PersistentAuthenticationStateProvider (PersistentAuthenticationStateProvider.cs) est un AuthenticationStateProvider côté client qui détermine l’état d’authentification de l’utilisateur en recherchant les données conservées dans la page quand elle a été rendue sur le serveur. L’état d’authentification est fixe pour la durée de vie de l’application WebAssembly.
Si l’utilisateur doit se connecter ou se déconnecter, un rechargement complet de la page est nécessaire.
L’exemple d’application fournit un nom d’utilisateur et un e-mail seulement à des fins d’affichage.
Sérialisez uniquement les revendications de nom et de rôle.
Cette section s’applique uniquement au modèle non BFF (Auto interactif) et au modèle BFF (Auto interactif) et à leurs exemples d’applications.
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 exemples de projets de solution configurent l’authentification par jeton OIDC et JWT dans leurs Program fichiers pour rendre les paramètres de configuration facilement accessibles grâce à la complétion 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 projet BlazorWebAppOidc ou BlazorWebAppOidcServer, ajoutez la configuration JSON suivante :
"Authentication": {
"Schemes": {
"MicrosoftOidc": {
"Authority": "https://login.microsoftonline.com/{TENANT ID (BLAZOR APP)}/v2.0",
"ClientId": "{CLIENT ID (BLAZOR APP)}",
"CallbackPath": "/signin-oidc",
"SignedOutCallbackPath": "/signout-callback-oidc",
"RemoteSignOutPath": "/signout-oidc",
"SignedOutRedirectUri": "/",
"Scope": [
"openid",
"profile",
"offline_access",
"{APP ID URI (WEB API)}/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 :
-
{TENANT ID (BLAZOR APP)}: ID de locataire de l’application Blazor . -
{CLIENT ID (BLAZOR APP)}: ID client de l’application Blazor . -
{APP ID URI (WEB API)}: URI d’ID d’application de l’API web.
L’autorité « commune » (https://login.microsoftonline.com/common/v2.0) doit être utilisée pour les applications multi-abonnés. Pour utiliser l’autorité « commune » pour les applications monolocataires, consultez la section Utiliser l’autorité « commune » pour les applications à locataire unique .
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.
Supprimez les lignes suivantes du Program fichier :
- oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
- oidcOptions.Scope.Add("...");
- oidcOptions.CallbackPath = new PathString("...");
- oidcOptions.SignedOutCallbackPath = new PathString("...");
- oidcOptions.RemoteSignOutPath = new PathString("...");
- oidcOptions.Authority = "...";
- oidcOptions.ClientId = "...";
Dans la ConfigureCookieOidc méthode de CookieOidcServiceCollectionExtensions.cs, supprimez la ligne suivante :
- oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
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 d’abonné ME-ID :
https://sts.windows.net/{TENANT ID} - ID externe Microsoft Entra :
https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0 - Type d’abonné 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 d’abonné ME-ID :
api://{CLIENT ID} - ID externe Microsoft Entra :
{CLIENT ID} - Type d’abonné 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 l'autorité « commune » pour les applications à locataire unique
Vous pouvez utiliser l’autorité « commune » pour les applications monolocataires, mais vous devez suivre les étapes suivantes pour implémenter un validateur d’émetteur personnalisé.
Ajoutez le Microsoft.IdentityModel.Validators package NuGet au projet BlazorWebAppOidc, BlazorWebAppOidcServer ou BlazorWebAppOidcBff.
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.
En haut du fichier Program, rendez l’espace de noms Microsoft.IdentityModel.Validators disponible :
using Microsoft.IdentityModel.Validators;
Utilisez le code suivant dans le Program fichier dans lequel les options OIDC sont configurées :
var microsoftIssuerValidator =
AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
oidcOptions.TokenValidationParameters.IssuerValidator =
microsoftIssuerValidator.Validate;
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).
Redirection vers la page d'accueil lors de la déconnexion
Le composant LogInOrOut (Layout/LogInOrOut.razor) définit un champ caché pour l'URL de retour (ReturnUrl) à l'URL actuelle (currentURL). Lorsque l'utilisateur se déconnecte de l'application, le fournisseur d'identité le renvoie à la page à partir de laquelle il s'est déconnecté. Si l'utilisateur se journalise à partir d'une page sécurisée, il est renvoyé à la même page sécurisée et repasse par le processus d'authentification. Ce flux d'authentification est raisonnable lorsque les utilisateurs doivent changer de compte régulièrement.
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>
Actualisation du jeton
La mise en œuvre du rafraîchissement cookie personnalisé (CookieOidcRefresher.cs) met automatiquement à jour les demandes de l'utilisateur lorsqu'elles expirent. L'implémentation actuelle s'attend à recevoir un jeton ID du point de terminaison du jeton en échange du jeton d'actualisation. Les revendications dans ce jeton d’identité sont ensuite utilisées pour écraser les revendications de l’utilisateur.
L'exemple de mise en œuvre n'inclut pas de code pour la requête de réclamations à partir du point de terminaison UserInfo lors de l'actualisation du jeton. Pour plus d’informations, veuillez consulter BlazorWebAppOidc AddOpenIdConnect with GetClaimsFromUserInfoEndpoint = true doesn't propogate [sic] role claims to client (dotnet/aspnetcore #58826).
Note
Certains fournisseurs d’identité ne retournent un jeton d’accès que quand on utilise un jeton d’actualisation. Le CookieOidcRefresher peut être mis à jour avec une logique supplémentaire pour continuer à utiliser l’ensemble antérieur de revendications stockées dans le module d’authentification cookie ou utiliser le jeton d’accès pour demander des revendications à partir du point de terminaison UserInfo.
Nonce de chiffrement
Un nombre aléatoire est une chaîne de caractères qui associe la session d'un client à un jeton ID afin de limiter les attaques par rejeu.
Si vous recevez une erreur de nonce pendant le développement et les tests d’authentification, utilisez une nouvelle session de navigateur InPrivate/incognito pour chaque exécution de test, quelle que soit l’importance du changement apporté à l’application ou à l’utilisateur de test, car des données cookie obsolètes peuvent entraîner une erreur de nonce. Pour plus d’informations, consultez la section Cookies et données de site.
Il n’est pas nécessaire d’utiliser un nonce lorsqu’un jeton d’actualisation est échangé contre un nouveau jeton d’accès. Dans l'exemple d'application, le CookieOidcRefresher (CookieOidcRefresher.cs) définit délibérément OpenIdConnectProtocolValidator.RequireNonce à false.
Rôles d’application pour les applications non inscrites auprès de Microsoft Entra (ME-ID)
Cette section concerne les applications qui n'utilisent pas Microsoft Entra ID (ME-ID) comme fournisseur d'identité. Pour les applications inscrites auprès de ME-ID, consultez la section Rôles d’application pour les applications inscrites auprès de Microsoft Entra (ME-ID).
Configurez le type de créance de rôle (TokenValidationParameters.RoleClaimType) dans le OpenIdConnectOptions de Program.cs :
oidcOptions.TokenValidationParameters.RoleClaimType = "{ROLE CLAIM TYPE}";
Pour de nombreux fournisseurs d’identité OIDC, le type de revendication de rôle est role. Consultez la documentation de votre fournisseur d'identité pour connaître la valeur correcte.
Remplacez la classe UserInfo dans le projet BlazorWebAppOidc.Client par la classe suivante.
UserInfo.cs :
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;
namespace BlazorWebAppOidc.Client;
// Add properties to this class and update the server and client
// AuthenticationStateProviders to expose more information about
// the authenticated user to the client.
public sealed class UserInfo
{
public required string UserId { get; init; }
public required string Name { get; init; }
public required string[] Roles { get; init; }
public const string UserIdClaimType = "sub";
public const string NameClaimType = "name";
private const string RoleClaimType = "role";
public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
new()
{
UserId = GetRequiredClaim(principal, UserIdClaimType),
Name = GetRequiredClaim(principal, NameClaimType),
Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
.ToArray(),
};
public ClaimsPrincipal ToClaimsPrincipal() =>
new(new ClaimsIdentity(
Roles.Select(role => new Claim(RoleClaimType, role))
.Concat([
new Claim(UserIdClaimType, UserId),
new Claim(NameClaimType, Name),
]),
authenticationType: nameof(UserInfo),
nameType: NameClaimType,
roleType: RoleClaimType));
private static string GetRequiredClaim(ClaimsPrincipal principal,
string claimType) =>
principal.FindFirst(claimType)?.Value ??
throw new InvalidOperationException(
$"Could not find required '{claimType}' claim.");
}
À ce stade, les composants Razor peuvent adopter une autorisation basée sur des rôles et basée sur des stratégies. Les rôles d’application apparaissent dans les revendications role, une revendication par rôle.
Rôles d’application pour les applications inscrites auprès de Microsoft Entra (ME-ID)
Utilisez les instructions de cette section pour implémenter des rôles d’application, des groupes de sécurité ME-ID et des rôles d’administrateur ME-ID intégrés pour les applications à l’aide de Microsoft Entra ID (ME-ID).
L’approche décrite dans cette section configure ME-ID pour envoyer des groupes et des rôles dans l’en-tête cookie d’authentification. Lorsque les utilisateurs ne sont membres que de quelques groupes et rôles de sécurité, l’approche suivante doit fonctionner pour la plupart des plateformes d’hébergement sans rencontrer de problème où les en-têtes sont trop longs, par exemple avec l’hébergement IIS qui a une limite de longueur d’en-tête par défaut de 16 Ko (MaxRequestBytes). Si la longueur d’en-tête est un problème en raison de l’appartenance à un groupe ou à un rôle élevé, nous vous recommandons de ne pas suivre les instructions de cette section en faveur de l’implémentation de Microsoft Graph pour obtenir séparément les groupes et rôles d’un utilisateur à partir de ME-ID, une approche qui n’augmente pas la taille de l’authentification cookie. Pour plus d’informations, consultez Requête incorrecte - Requête trop longue - Serveur IIS (dotnet/aspnetcore #57545).
Configurez le type de revendication de rôle (TokenValidationParameters.RoleClaimType) dans OpenIdConnectOptions de Program.cs. Définissez la valeur sur roles :
oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
Bien que vous ne puissiez pas attribuer de rôles à des groupes sans compte ME-ID Premium, vous pouvez attribuer des rôles à des utilisateurs et recevoir des revendications de rôle pour des utilisateurs avec un compte Azure standard. Les conseils de cette section ne nécessitent pas de compte ME-ID Premium.
Lorsque vous utilisez le répertoire par défaut, suivez les instructions détaillées dans Ajouter des rôles d’application dans votre application et les recevoir dans le jeton (documentation ME-ID) pour configurer et attribuer des rôles. Si vous n’utilisez pas le répertoire par défaut, modifiez le manifeste de l’application dans le portail Azure pour établir manuellement les rôles de l’application dans l’entrée appRoles du fichier manifeste. Pour plus d’informations, consultez Configurer la revendication de rôle (documentation ME-ID).
Les groupes de sécurité Azure d'un utilisateur arrivent dans les réclamations groups, et les attributions de rôles d'administrateur ME-ID intégrés d'un utilisateur arrivent dans les réclamations identifiants bien connus (wids). Les valeurs des deux types de créances sont des GUID. Lorsqu’elles sont reçues par l’application, ces revendications peuvent être utilisées pour établir une autorisation de rôle et de stratégie dans les composants Razor.
Dans le manifeste de l’application dans le portail Azure, définissez l’attribut groupMembershipClaims à All. Une valeur de All entraîne l’envoi par ME-ID de tous les groupes de sécurité/distribution (revendications groups) et rôles (revendications wids) de l’utilisateur connecté. Pour définir l’attribut groupMembershipClaims :
- Ouvrez l’inscription de l’application dans le portail Azure.
- Sélectionnez Gérer>Manifeste dans la barre latérale.
- Recherchez l’attribut
groupMembershipClaims. - Définissez la valeur sur
All("groupMembershipClaims": "All"). - Sélectionnez le bouton Enregistrer.
Remplacez la classe UserInfo dans le projet BlazorWebAppOidc.Client par la classe suivante.
UserInfo.cs :
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;
namespace BlazorWebAppOidc.Client;
// Add properties to this class and update the server and client
// AuthenticationStateProviders to expose more information about
// the authenticated user to the client.
public sealed class UserInfo
{
public required string UserId { get; init; }
public required string Name { get; init; }
public required string[] Roles { get; init; }
public required string[] Groups { get; init; }
public required string[] Wids { get; init; }
public const string UserIdClaimType = "sub";
public const string NameClaimType = "name";
private const string RoleClaimType = "roles";
private const string GroupsClaimType = "groups";
private const string WidsClaimType = "wids";
public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
new()
{
UserId = GetRequiredClaim(principal, UserIdClaimType),
Name = GetRequiredClaim(principal, NameClaimType),
Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
.ToArray(),
Groups = principal.FindAll(GroupsClaimType).Select(c => c.Value)
.ToArray(),
Wids = principal.FindAll(WidsClaimType).Select(c => c.Value)
.ToArray(),
};
public ClaimsPrincipal ToClaimsPrincipal() =>
new(new ClaimsIdentity(
Roles.Select(role => new Claim(RoleClaimType, role))
.Concat(Groups.Select(role => new Claim(GroupsClaimType, role)))
.Concat(Wids.Select(role => new Claim(WidsClaimType, role)))
.Concat([
new Claim(UserIdClaimType, UserId),
new Claim(NameClaimType, Name),
]),
authenticationType: nameof(UserInfo),
nameType: NameClaimType,
roleType: RoleClaimType));
private static string GetRequiredClaim(ClaimsPrincipal principal,
string claimType) =>
principal.FindFirst(claimType)?.Value ??
throw new InvalidOperationException(
$"Could not find required '{claimType}' claim.");
}
À ce stade, les composants Razor peuvent adopter une autorisation basée sur des rôles et basée sur des stratégies :
- Les rôles d’application apparaissent dans les revendications
roles, une revendication par rôle. - Les groupes de sécurité apparaissent dans les revendications
groups, une revendication par groupe. Les GUID des groupes de sécurité apparaissent dans le portail Azure lorsque vous créez un groupe de sécurité et sont répertoriés lors de la sélection de Identity>Vue d’ensemble>Groupes>Affichage. - Les rôles d’administrateur ME-ID intégrés apparaissent dans les revendications
wids, une revendication par rôle. La revendicationwidsavec la valeurb79fbf4d-3ef9-4689-8143-76b194e85509est toujours envoyée par ME-ID pour les comptes non invités du locataire et ne fait pas référence à un rôle d’administrateur. Les GUID de rôle d’administrateur (ID de modèle de rôle) apparaissent dans le portail Azure lors de la sélection de Rôles et administrateurs, suivis des points de suspension (...) >Description du rôle répertorié. Les identifiants de modèle de rôle sont également listés dans les rôles par défaut de Microsoft Entra (documentation Entra).
Alternative : Gestion des jetons d’accès Duende
Dans l’exemple d’application, une implémentation d’actualisation personnalisée cookie (CookieOidcRefresher.cs) est utilisée pour effectuer l’actualisation automatique des jetons non interactifs. Vous trouverez une autre solution dans le package open sourceDuende.AccessTokenManagement.OpenIdConnect.
La gestion des jetons d’accès Duende fournit des fonctionnalités de gestion automatique des jetons d’accès pour les applications web .NET Worker et ASP.NET Core, notamment Blazor, sans avoir à ajouter d’actualisation personnalisée cookie .
Une fois le package installé, supprimez et ajoutez la CookieOidcRefresher gestion des jetons d’accès pour l’utilisateur actuellement connecté dans le Program fichier :
// Add services for token management
builder.Services.AddOpenIdConnectAccessTokenManagement();
// Register a typed HTTP client with token management support
builder.Services.AddHttpClient<InvoiceClient>(client =>
{
client.BaseAddress = new Uri("https://api.example.com/invoices/");
})
.AddUserAccessTokenHandler();
Le client HTTP typé (ou le client HTTP nommé, s’il est implémenté) dispose d’une gestion automatique de la durée de vie des jetons d’accès pour le compte de l’utilisateur actuellement connecté, y compris la gestion transparente des jetons d’actualisation.
Pour plus d’informations, consultez la documentation Duende Access Token Management pour Blazor.
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.
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 IP (Identity Provider)
Les erreurs les plus courantes sont provoquées par une configuration incorrecte. Voici quelques exemples :
- Selon les besoins du scénario, une autorité, une instance, un ID de locataire, un domaine de locataire, un ID client ou un URI de redirection manquant ou incorrect empêche une application d’authentifier les clients.
- Les étendues de requêtes erronées empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Des autorisations d’API serveur incorrectes ou manquantes empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Exécution de l’application sur un autre port que celui configuré dans l’URI de redirection de l’inscription d’application du fournisseur d’identité. 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'adresse IP ou l’application serveur à l’aide des outils de développement du navigateur. Souvent, un message d'erreur exact ou un message contenant un indice sur la cause du problème est renvoyé au client par l'application serveur ou l'adresse IP après avoir effectué une demande. Vous trouverez des conseils d’aide sur les outils de développement dans les articles suivants :
- Google Chrome (documentation Google)
- Microsoft Edge
- Mozilla Firefox (documentation Mozilla)
L’équipe de documentation peut répondre aux commentaires et bogues relatifs aux articles (ouvrez un problème à partir de la section de commentaires de cette page). Toutefois, elle ne peut pas fournir de support produit. Plusieurs forums de support publics sont disponibles pour vous aider à résoudre les problèmes liés à une application. Nous recommandons ce qui suit :
Les forums précédents ne sont pas détenus ou contrôlés par Microsoft.
Pour les rapports de bogues de framework reproductibles, non liés à la sécurité, non sensibles et non confidentiels, ouvrez un problème auprès de l’unité de produit ASP.NET Core. N’ouvrez pas de problème auprès de l’unité de produit tant que vous n’avez pas investigué de manière approfondie la cause du problème, sans pouvoir le résoudre par vous-même ou avec l’aide de la communauté sur un forum de support public. L’unité de produit ne peut pas résoudre les problèmes d’applications individuelles qui sont défaillantes en raison d’une mauvaise configuration ou de cas d’usage impliquant des services tiers. Si un rapport est de nature sensible ou confidentielle, ou s’il décrit une faille de sécurité potentielle 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 rappel de la connexion à partir de ME-ID :
- Erreur :
unauthorized_client - Description :
AADB2C90058: The provided application is not configured to allow public clients.
Pour résoudre l’erreur :
- Dans le portail Azure, accédez au manifeste de l’application.
- Affectez à l’attribut
allowPublicClientla valeurnulloutrue.
- Erreur :
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
- Microsoft Edge :
- 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 exemplehttps://localhost:5001).
- Microsoft Edge : Utilisez
- 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 :
- Effacez les caches de package NuGet du système local en exécutant
dotnet nuget locals all --clearà partir d’un interpréteur de commandes. - Supprimez les dossiers
binetobjdu projet. - Restaurez et reconstruisez le projet.
- 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.AppHostprojet. - 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
-
Référentiel GitHub
AzureAD/microsoft-identity-web: aide utile sur l’implémentation de Microsoft Identity Web pour Microsoft Entra ID et Azure Active Directory B2C pour les applications ASP.NET Core, incluant des liens vers des exemples d’applications et la documentation Azure associée. Actuellement, les Blazor Web App ne sont pas ciblées explicitement par la documentation Azure, mais l’installation et la configuration d’une Blazor Web App pour ME-ID et l’hébergement Azure sont identiques à celles des applications web ASP.NET Core. -
AuthenticationStateProviderservice - Gérer l’état d’authentification dans Blazor Web App
-
Jeton d’actualisation pendant la requête HTTP dans le serveur interactif Blazor avec OIDC (
dotnet/aspnetcore#55213) - Sécuriser les données dandBlazor Web App s avec Interactive Auto rendering
-
Comment accéder à un
AuthenticationStateProviderdepuis unDelegatingHandler