Sécuriser une application autonome ASP.NET Core Blazor WebAssembly avec la bibliothèque d’authentification
Remarque
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 de cet article.
Avertissement
Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la stratégie de support .NET et .NET Core. Pour la version actuelle, consultez la version .NET 9 de cet article.
Important
Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.
Pour la version actuelle, consultez la version .NET 9 de cet article.
Cet article explique comment sécuriser une application autonome ASP.NET Core Blazor WebAssembly avec la bibliothèque d’authentification Blazor WebAssembly.
La bibliothèque d’authentification Blazor WebAssembly (Authentication.js
) prend uniquement en charge le flux de code d’autorisation PKCE (Proof Key for Code Exchange) via la Microsoft Authentication Library (MSAL, msal.js
). Pour implémenter d’autres flux d’octroi, accédez aux instructions MSAL pour implémenter la bibliothèque MSAL directement, mais nous ne prenons pas en charge ni ne recommandons l’utilisation de flux d’octroi autres que PKCE pour les applications Blazor.
Pour obtenir des conseils sur Microsoft Entra (ME-ID) et Azure Active Directory B2C (AAD B2C), ne suivez pas les conseils de cette rubrique. Consultez Sécuriser une application autonome Blazor WebAssembly ASP.NET Core avec ID Microsoft Entra ou Sécuriser une application autonome Blazor WebAssembly ASP.NET Core avec Azure Active Directory B2C.
Pour obtenir une couverture supplémentaire du scénario de sécurité, après avoir lu cet article, consultez ASP.NET Core Blazor WebAssembly scénarios de sécurité supplémentaires.
Procédure pas à pas
Les sous-sections de la procédure pas à pas expliquent comment :
- Inscrire une application
- Créer l’application Blazor
- Exécuter l’application
Inscrire une application
Inscrivez une application auprès d’un fournisseur d’identité (Identity Provider) OIDC (OpenID Connect) en suivant les conseils d’aide fournis par le responsable du fournisseur d’identité.
Enregistrez les informations suivantes :
- Autorité (par exemple
https://accounts.google.com/
). - ID d’application (client) (par exemple
2...7-e...q.apps.googleusercontent.com
). - Configuration supplémentaire du fournisseur d’identité (consultez la documentation du fournisseur d’identité).
Remarque
Le fournisseur d’identité doit utiliser OIDC. Par exemple, le fournisseur d’identité de Facebook n’est pas un fournisseur conforme à OIDC. Les conseils d’aide fournis dans cette rubrique ne s’appliquent donc pas au fournisseur d’identité de Facebook. Pour plus d’informations, consultez Sécuriser ASP.NET Core Blazor WebAssembly.
Créer l’application Blazor
Pour créer une application Blazor WebAssembly autonome qui utilise la bibliothèque Microsoft.AspNetCore.Components.WebAssembly.Authentication
, suivez les conseils d’aide relatifs au choix des outils. Si vous ajoutez la prise en charge de l’authentification, consultez la section Parties de l’application de cet article pour obtenir des conseils d’aide sur l’installation et la configuration de l’application.
Pour créer un projet Blazor WebAssembly avec un mécanisme d’authentification :
Une fois que vous avez choisi le modèle Application Blazor WebAssembly, affectez à Type d’authentification la valeur Comptes individuels.
Une fois que vous avez choisi le modèle Application Blazor WebAssembly, affectez à Type d’authentification la valeur Comptes individuels. Vérifiez que la case Hébergé avec ASP.NET Core n’est pas cochée.
La sélection de Comptes individuels permet d’utiliser le système Identity d’ASP.NET Core. Cette sélection ajoute la prise en charge de l’authentification. Elle n’entraîne pas le stockage des utilisateurs dans une base de données. Les sections suivantes de cet article fournissent plus de détails.
Configurer l’application
Configurez l’application en suivant les conseils d’aide relatifs au fournisseur d’identité. Au minimum, l’application nécessite les paramètres de configuration Local:Authority
et Local:ClientId
dans le fichier wwwroot/appsettings.json
de l’application :
{
"Local": {
"Authority": "{AUTHORITY}",
"ClientId": "{CLIENT ID}"
}
}
Exemple OIDC Google OAuth 2.0 pour une application qui s’exécute à l’adresse localhost
sur le port 5001 :
{
"Local": {
"Authority": "https://accounts.google.com/",
"ClientId": "2...7-e...q.apps.googleusercontent.com",
"PostLogoutRedirectUri": "https://localhost:5001/authentication/logout-callback",
"RedirectUri": "https://localhost:5001/authentication/login-callback",
"ResponseType": "code"
}
}
L’URI de redirection (https://localhost:5001/authentication/login-callback
) est inscrit dans la console d’API Google, dans Informations d’identification>{NAME}
>URI de redirection autorisés, où {NAME}
représente le nom de client de l’application dans la liste des applications avec ID client OAuth 2.0 de la console d’API Google.
Remarque
L’indication du numéro de port d’un URI de redirection localhost
n’est pas nécessaire pour certains fournisseurs d’identité OIDC, conformément à la spécification OAuth 2.0. Certains fournisseurs d’identité permettent à l’URI de redirection des adresses de bouclage d’omettre le port. D’autres autorisent l’utilisation d’un caractère générique pour le numéro de port (par exemple *
). Pour plus d’informations, consultez la documentation du fournisseur d’identité.
Exécuter l’application
Utilisez l’une des approches suivantes pour exécuter l’application :
- Visual Studio
- Sélectionnez le bouton Run.
- Utilisez Déboguer>Démarrer le débogage dans le menu.
- Appuyez sur F5.
- Interpréteur de commandes .NET CLI : Exécutez la commande
dotnet watch
(oudotnet run
) à partir du dossier de l’application.
Parties de l’application
Cette section décrit les parties d’une application générées à partir du modèle de projet Blazor WebAssembly ainsi que la façon dont l’application est configurée. Il n’existe aucun conseil d’aide spécifique à suivre dans cette section pour une application de base, si vous avez créé l’application en suivant les conseils d’aide de la section Procédure pas à pas. Les conseils d’aide de cette section sont utiles pour mettre à jour une application afin d’authentifier et d’autoriser les utilisateurs. Toutefois, il existe une autre approche pour la mise à jour d’une application. Elle consiste à créer une application à partir des conseils d’aide de la section Procédure pas à pas, et à déplacer les composants, les classes et les ressources de l’application à mettre à jour vers la nouvelle application.
Package d’authentification
Quand une application est créée pour utiliser des comptes d’utilisateurs individuels, elle reçoit automatiquement une référence de package pour le package Microsoft.AspNetCore.Components.WebAssembly.Authentication
. Le package fournit un ensemble de primitives qui permettent à l’application d’authentifier les utilisateurs et d’obtenir des jetons pour appeler les API protégées.
Si vous ajoutez l’authentification à une application, ajoutez manuellement le package Microsoft.AspNetCore.Components.WebAssembly.Authentication
à l’application.
Remarque
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.
Prise en charge du service d’authentification
La prise en charge de l’authentification des utilisateurs à l’aide d’OIDC (OpenID Connect) est inscrite auprès du conteneur de services avec la méthode d’extension AddOidcAuthentication fournie par le package Microsoft.AspNetCore.Components.WebAssembly.Authentication
.
La méthode AddOidcAuthentication accepte un rappel pour configurer les paramètres nécessaires à l’authentification d’une application à l’aide d’OIDC. Les valeurs nécessaires à la configuration de l’application peuvent être obtenues auprès du fournisseur d’identité conforme à OIDC. Obtenez les valeurs quand vous inscrivez l’application, ce qui se produit généralement dans son portail en ligne.
Dans le cas d’une nouvelle application, indiquez les valeurs pour les espaces réservés {AUTHORITY}
et {CLIENT ID}
dans la configuration suivante. Indiquez les autres valeurs de configuration nécessaires à utiliser avec le fournisseur d’identité de l’application. L’exemple concerne Google, qui nécessite PostLogoutRedirectUri
, RedirectUri
et ResponseType
. Si vous ajoutez l’authentification à une application, ajoutez manuellement le code et la configuration suivants à l’application avec des valeurs pour les espaces réservés et autres valeurs de configuration.
Dans le fichier Program
:
builder.Services.AddOidcAuthentication(options =>
{
builder.Configuration.Bind("Local", options.ProviderOptions);
});
Configuration wwwroot/appsettings.json
La configuration est fournie par le fichier wwwroot/appsettings.json
:
{
"Local": {
"Authority": "{AUTHORITY}",
"ClientId": "{CLIENT ID}"
}
}
Étendues de jeton d’accès
Le modèle Blazor WebAssembly configure automatiquement les étendues par défaut pour openid
et profile
.
Le modèle Blazor WebAssembly ne configure pas automatiquement l’application afin qu’elle demande un jeton d’accès pour une API sécurisée. Pour provisionner un jeton d’accès dans le cadre du flux de connexion, ajoutez l’étendue aux étendues de jeton par défaut de OidcProviderOptions. Si vous ajoutez l’authentification à une application, ajoutez manuellement le code suivant, puis configurez l’URI d’étendue.
Dans le fichier Program
:
builder.Services.AddOidcAuthentication(options =>
{
...
options.ProviderOptions.DefaultScopes.Add("{SCOPE URI}");
});
Pour plus d’informations, consultez les sections suivantes de l’article Scénarios supplémentaires :
Fichier Imports
L’espace de noms Microsoft.AspNetCore.Components.Authorization est rendu disponible dans l’ensemble de l’application via le fichier _Imports.razor
:
@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}
@using {APPLICATION ASSEMBLY}.Shared
Page d'index
La page d’index (wwwroot/index.html
) comprend un script qui définit AuthenticationService
en JavaScript. AuthenticationService
gère les détails de bas niveau du protocole OIDC. L’application appelle de manière interne les méthodes définies dans le script pour effectuer les opérations d’authentification.
<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>
Composant d’application
Le composant App
(App.razor
) est similaire au composant App
présent dans les applications Blazor Server :
- Le composant AuthorizeRouteView vérifie que l’utilisateur actuel est autorisé à accéder à une page donnée, ou affiche le composant
RedirectToLogin
. - Le composant
RedirectToLogin
gère la redirection des utilisateurs non autorisés vers la page de connexion.
- Le composant CascadingAuthenticationState gère l’exposition de AuthenticationState au rest de l’application.
- Le composant AuthorizeRouteView vérifie que l’utilisateur actuel est autorisé à accéder à une page donnée, ou affiche le composant
RedirectToLogin
. - Le composant
RedirectToLogin
gère la redirection des utilisateurs non autorisés vers la page de connexion.
En raison des changements apportés au framework dans les différentes versions d’ASP.NET Core, la syntaxe Razor du composant App
(App.razor
) n’est pas affichée dans cette section. Pour inspecter la syntaxe du composant d’une version donnée, utilisez l’une des approches suivantes :
Créez une application provisionnée pour l’authentification à partir du modèle de projet Blazor WebAssembly par défaut correspondant à la version d’ASP.NET Core que vous prévoyez d’utiliser. Inspectez le composant
App
(App.razor
) dans l’application générée.Inspectez le composant
App
(App.razor
) dans source de référence. Sélectionnez la version dans le sélecteur de branche, puis recherchez le composant dans le dossierProjectTemplates
du référentiel, car il a été déplacé au fil des années.Remarque
Les liens de documentation vers la source de référence .NET chargent généralement la branche par défaut du référentiel, qui représente le développement actuel pour la prochaine version de .NET. Pour sélectionner une balise pour une version spécifique, utilisez la liste déroulante Échanger les branches ou les balises. Pour plus d’informations, consultez Comment sélectionner une balise de version du code source ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Composant RedirectToLogin
Le composant RedirectToLogin
(RedirectToLogin.razor
) :
- Gère la redirection des utilisateurs non autorisés vers la page de connexion.
- L’URL actuelle à laquelle l’utilisateur tente d’accéder est conservée pour permettre à l’utilisateur de retourner à cette page en cas d’authentification réussie avec :
- État de l’historique de navigation dans ASP.NET Core dans .NET 7 ou une version ultérieure.
- Chaîne de requête dans ASP.NET Core dans .NET 6 ou une version antérieure.
Inspectez le composant RedirectToLogin
dans source de référence. L’emplacement du composant ayant changé au fil du temps, servez-vous des outils de recherche GitHub pour le retrouver.
Remarque
Les liens de documentation vers la source de référence .NET chargent généralement la branche par défaut du référentiel, qui représente le développement actuel pour la prochaine version de .NET. Pour sélectionner une balise pour une version spécifique, utilisez la liste déroulante Échanger les branches ou les balises. Pour plus d’informations, consultez Comment sélectionner une balise de version du code source ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Composant LoginDisplay
Le composant LoginDisplay
(LoginDisplay.razor
) est affiché dans le composant MainLayout
(MainLayout.razor
) et gère les comportements suivants :
- Pour les utilisateurs authentifiés :
- Affiche le nom d’utilisateur actuel.
- Propose un lien vers la page de profil utilisateur dans ASP.NET Core Identity.
- Propose un bouton pour se déconnecter de l’application.
- Pour les utilisateurs anonymes :
- Permet de s’inscrire.
- Permet de se connecter.
En raison des changements apportés au framework dans les différentes versions d’ASP.NET Core, la syntaxe Razor du composant LoginDisplay
n’est pas affichée dans cette section. Pour inspecter la syntaxe du composant d’une version donnée, utilisez l’une des approches suivantes :
Créez une application provisionnée pour l’authentification à partir du modèle de projet Blazor WebAssembly par défaut correspondant à la version d’ASP.NET Core que vous prévoyez d’utiliser. Inspectez le composant
LoginDisplay
dans l’application générée.Inspectez le composant
LoginDisplay
dans la source de référence. L’emplacement du composant ayant changé au fil du temps, servez-vous des outils de recherche GitHub pour le retrouver. Le contenu mis en modèle pourHosted
égal àtrue
est utilisé.Remarque
Les liens de documentation vers la source de référence .NET chargent généralement la branche par défaut du référentiel, qui représente le développement actuel pour la prochaine version de .NET. Pour sélectionner une balise pour une version spécifique, utilisez la liste déroulante Échanger les branches ou les balises. Pour plus d’informations, consultez Comment sélectionner une balise de version du code source ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Composant Authentication
La page produite par le composant Authentication
(Pages/Authentication.razor
) définit les routes nécessaires à la gestion des différentes phases d’authentification.
Le composant RemoteAuthenticatorView :
- Est fourni par le package
Microsoft.AspNetCore.Components.WebAssembly.Authentication
. - Gère l’exécution des actions appropriées à chaque phase de l’authentification.
@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
<RemoteAuthenticatorView Action="@Action" />
@code {
[Parameter]
public string? Action { get; set; }
}
Remarque
Les types références null (NRT, nullable reference types) et l’analyse statique de l’état nul du compilateur .NET sont pris en charge dans ASP.NET Core dans .NET 6 ou une version ultérieure. Avant la publication d’ASP.NET Core dans .NET 6, le type string
apparaît sans la désignation de type nul (?
).
Résolution des problèmes
Logging
Pour activer la journalisation de débogage ou de trace pour l’authentification Blazor WebAssembly, consultez la section Journalisation d’authentification côté client de la Journalisation Blazor ASP.NET Core avec le sélecteur de version d’article défini sur ASP.NET Core 7.0 ou une version ultérieure.
Erreurs courantes
Mauvaise configuration de l’application ou du fournisseur d’identité (Identity Provider)
Les erreurs les plus courantes sont provoquées par une configuration incorrecte. Voici quelques exemples :
- Selon les besoins du scénario, une autorité, une instance, un ID de locataire, un domaine de locataire, un ID client ou un URI de redirection manquant ou incorrect empêche une application d’authentifier les clients.
- Les étendues de requêtes erronées empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Des autorisations d’API serveur incorrectes ou manquantes empêchent les clients d’accéder aux points de terminaison d’API web du serveur.
- Exécution de l’application sur un autre port que celui configuré dans l’URI de redirection de l’inscription d’application de l’IP. Notez qu’un port n’est pas requis pour Microsoft Entra ID et pour une application s’exécutant à une adresse de test de développement
localhost
. Cependant, la configuration du port de l’application et le port où l’application s’exécute doivent correspondre pour les adresses non-localhost
.
Les sections de configuration présentes dans les conseils d’aide de cet article montrent des exemples de configuration appropriée. Examinez attentivement chaque section de l’article à la recherche d’une mauvaise configuration de l’application et du fournisseur d’identité.
Si la configuration semble correcte :
Analysez les journaux des applications.
Examinez le trafic réseau entre l’application cliente et le fournisseur d’identité ou l’application serveur à l’aide des outils de développement du navigateur. Bien souvent, un message d’erreur exact ou un message indiquant la cause du problème est retourné au client par le fournisseur d’identité ou l’application serveur, une fois qu’une demande a été effectuée. Vous trouverez des conseils d’aide sur les outils de développement dans les articles suivants :
- Google Chrome (documentation Google)
- Microsoft Edge
- Mozilla Firefox (documentation Mozilla)
Pour les versions de Blazor dans lesquelles un jeton JSON Web Token (JWT) est utilisé, décodez le contenu du jeton utilisé pour authentifier un client ou pour accéder à une API web de serveur, en fonction de l’emplacement du problème. Pour plus d’informations, consultez Inspecter le contenu d’un jeton JWT (JSON Web Token).
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
allowPublicClient
la valeurnull
outrue
.
- 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’applications
- 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 SDK .NET Core sur l’ordinateur de développement ou la modification des versions de package au sein de l’application. Dans certains cas, les packages incohérents peuvent bloquer une application quand vous effectuez des mises à niveau majeures. Vous pouvez résoudre la plupart de ces problèmes en suivant les instructions suivantes :
- Effacez les caches de package NuGet du système local en exécutant
dotnet nuget locals all --clear
à partir d’un interpréteur de commandes. - Supprimez les dossiers
bin
etobj
du projet. - Restaurez et regénérez le projet.
- Supprimez tous les fichiers du dossier de déploiement sur le serveur avant de redéployer l’application.
Remarque
L’utilisation de versions de package incompatibles avec le framework cible de l’application n’est pas prise en charge. Pour plus d’informations sur un package, utilisez la Galerie NuGet ou l’Explorateur de packages FuGet.
Exécuter l’application Server
Quand vous testez et résolvez les problèmes liés à une solution Blazor WebAssembly hébergée, vérifiez que vous exécutez l’application à partir du projet Server
.
Inspecter l’utilisateur
Le composant User
suivant peut être utilisé directement dans les applications, ou servir de base à une personnalisation supplémentaire.
User.razor
:
@page "/user"
@attribute [Authorize]
@using System.Text.Json
@using System.Security.Claims
@inject IAccessTokenProvider AuthorizationService
<h1>@AuthenticatedUser?.Identity?.Name</h1>
<h2>Claims</h2>
@foreach (var claim in AuthenticatedUser?.Claims ?? Array.Empty<Claim>())
{
<p class="claim">@(claim.Type): @claim.Value</p>
}
<h2>Access token</h2>
<p id="access-token">@AccessToken?.Value</p>
<h2>Access token claims</h2>
@foreach (var claim in GetAccessTokenClaims())
{
<p>@(claim.Key): @claim.Value.ToString()</p>
}
@if (AccessToken != null)
{
<h2>Access token expires</h2>
<p>Current time: <span id="current-time">@DateTimeOffset.Now</span></p>
<p id="access-token-expires">@AccessToken.Expires</p>
<h2>Access token granted scopes (as reported by the API)</h2>
@foreach (var scope in AccessToken.GrantedScopes)
{
<p>Scope: @scope</p>
}
}
@code {
[CascadingParameter]
private Task<AuthenticationState> AuthenticationState { get; set; }
public ClaimsPrincipal AuthenticatedUser { get; set; }
public AccessToken AccessToken { get; set; }
protected override async Task OnInitializedAsync()
{
await base.OnInitializedAsync();
var state = await AuthenticationState;
var accessTokenResult = await AuthorizationService.RequestAccessToken();
if (!accessTokenResult.TryGetToken(out var token))
{
throw new InvalidOperationException(
"Failed to provision the access token.");
}
AccessToken = token;
AuthenticatedUser = state.User;
}
protected IDictionary<string, object> GetAccessTokenClaims()
{
if (AccessToken == null)
{
return new Dictionary<string, object>();
}
// header.payload.signature
var payload = AccessToken.Value.Split(".")[1];
var base64Payload = payload.Replace('-', '+').Replace('_', '/')
.PadRight(payload.Length + (4 - payload.Length % 4) % 4, '=');
return JsonSerializer.Deserialize<IDictionary<string, object>>(
Convert.FromBase64String(base64Payload));
}
}
Inspecter le contenu d’un jeton JWT (JSON Web Token)
Pour décoder un jeton JWT (JSON Web Token), utilisez l’outil jwt.ms de Microsoft. Les valeurs de l’IU ne quittent jamais votre navigateur.
Exemple de jeton JWT codé (raccourci pour des raisons d’affichage) :
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j ... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q
Exemple JWT décodé par l’outil pour une application qui s’authentifie auprès d’Azure AAD B2C :
{
"typ": "JWT",
"alg": "RS256",
"kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
"exp": 1610059429,
"nbf": 1610055829,
"ver": "1.0",
"iss": "https://mysiteb2c.b2clogin.com/11112222-bbbb-3333-cccc-4444dddd5555/v2.0/",
"sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"nonce": "bbbb0000-cccc-1111-dddd-2222eeee3333",
"iat": 1610055829,
"auth_time": 1610055822,
"idp": "idp.com",
"tfp": "B2C_1_signupsignin"
}.[Signature]
Ressources supplémentaires
- Autres scénarios de sécurité ASP.NET Core Blazor WebAssembly
- Requêtes d’API web non authentifiées ou non autorisées dans une application avec un client par défaut sécurisé
- Configurer ASP.NET Core pour une utilisation avec des serveurs proxy et des équilibreurs de charge. Cet article fournit des conseils sur les aspects suivants :
- Utilisation du middleware Forwarded Headers pour préserver les informations de schéma HTTPS sur les serveurs proxy et les réseaux internes.
- Autres scénarios et cas d’usage, notamment la configuration manuelle de schéma, la modification des chemins de requêtes pour assurer le bon routage des requêtes et le transfert du schéma de requête pour les proxys inverses Linux et non IIS.