Sécuriser ASP.NET Core Blazor WebAssembly

Les applications Blazor WebAssembly sont sécurisées de la même manière que les applications monopages (SPA). Il existe plusieurs façons d’authentifier les utilisateurs auprès des applications monopages, mais l’approche la plus courante et la plus complète consiste à utiliser une implémentation basée sur le protocole OAuth 2.0, comme OpenID Connect (OIDC).

La documentation de sécurité Blazor WebAssembly se concentre principalement sur la façon d’accomplir des tâches d’authentification et d’autorisation des utilisateurs. Pour obtenir la couverture générale de concept OAuth 2.0/OIDC, consultez l’article de présentation générale et sa section Ressources supplémentaires.

Sécurité côté client/SPA des données sensibles et des informations d’identification

Une application Blazor WebAssembly de codebase .NET/C# est fournie aux clients et le code de l’application ne peut pas être protégé contre l’inspection et la falsification par les utilisateurs. Ne placez jamais d’informations d’identification ou de secrets dans une Blazor WebAssembly application, comme les secrets d’application, les chaîne de connexion s, les mots de passe, le code .NET/C# privé ou d’autres données sensibles.

Pour protéger le code .NET/C# et utiliser les fonctionnalités de ASP.NET Core Data Protection pour sécuriser les données, utilisez une API web ASP.NET Core côté serveur. Demander à l’application Blazor WebAssembly côté client d’appeler l’API web côté serveur pour sécuriser les fonctionnalités de l’application et le traitement des données. Pour plus d’informations, consultez Appeler une API web à partir d’une application ASP.NET CoreBlazor et les articles de ce nœud.

Pour les tests de développement locaux, l’outil Secret Manager est recommandé pour sécuriser les données sensibles.

Bibliothèque d’authentification

Blazor WebAssemblyprend en charge l’authentification et l’autorisation d’applications à l’aide d’OIDC via la bibliothèque à l’aide de la Microsoft.AspNetCore.Components.WebAssembly.Authentication plateforme Microsoftidentity. La bibliothèque propose un ensemble de primitives pour assurer une authentification fluide auprès des back-ends ASP.NET Core. La bibliothèque peut s’authentifier auprès de n’importe quel fournisseur d’identité (ou IP, Identity Provider) prenant en charge OIDC, appelés fournisseurs OpenID (ou OP, OpenID Provider).

La prise en charge de l’authentification dans la Bibliothèque Blazor WebAssembly (Authentication.js) repose sur la Bibliothèque d’authentification Microsoft (MSAL, msal.js) qui est utilisée pour gérer les détails du protocole d’authentification sous-jacent. La Bibliothèque Blazor WebAssemblyprend en charge uniquement le flux de code d’autorisation avec PKCE (Proof Key for Code Exchange). L’octroi implicite n’est pas pris en charge.

D’autres options existent pour l’authentification des applications monopages, notamment l’utilisation de cookies SameSite. Cependant, la conception technique de Blazor WebAssembly a retenu OAuth et OIDC comme étant la meilleure option pour l’authentification dans les applications Blazor WebAssembly. L’authentification basée sur un jeton reposant sur des jetons JWT (JSON Web Tokens) a été préférée à l’authentification basée sur les cookie pour des raisons fonctionnelles et de sécurité :

• Les jetons n’étant pas envoyés dans toutes les requêtes, l’utilisation d’un protocole basé sur les jetons offre une surface d’attaque plus petite.
• Les points de terminaison serveur ne nécessitent pas de protection contre la falsification de requête intersites (CSRF), car les jetons sont envoyés explicitement au serveur. Cela vous permet d’héberger des applications Blazor WebAssembly avec des applications MVC ou Razor Pages.
• Les jetons ont des autorisations plus limitées que les cookies. Par exemple, les jetons ne permettent pas de gérer le compte d’utilisateur ou de changer le mot de passe d’un utilisateur, à moins que cette fonctionnalité soit explicitement implémentée.
• Les jetons ont une durée de vie courte (une heure), ce qui limite la fenêtre d’attaque. De plus, les jetons peuvent être révoqués à tout moment.
• Les jetons JWT autonomes offrent des garanties au client et au serveur eu égard au processus d’authentification. Par exemple, un client a les moyens de détecter et de valider l’authenticité des jetons qu’il reçoit et de déterminer s’ils ont été émis dans le cadre d’un processus d’authentification donné. Si un tiers tente de changer de jeton pendant le processus d’authentification, le client peut détecter le changement de jeton et éviter de l’utiliser.
• Avec OAuth et OIDC, le jetons n’attendent pas de l’agent utilisateur qu’il se comporte correctement en s’assurant que l’application est sûre.
• Les protocoles basés sur des jetons, comme OAuth et OIDC, permettent d’authentifier et d’autoriser les utilisateurs dans les applications Webassembly Blazor autonomes avec le même ensemble de caractéristiques de sécurité.

Important

Pour les versions de ASP.NET Core qui adoptent Duende Identity Server dans les modèles de projet Blazor, Duende Software peut vous demander de payer des frais de licence pour l’utilisation de Duende Identity Server en production. Pour plus d’informations, consultez Migrer de ASP.NET Core 5.0 vers 6.0.

Processus d’authentification avec OIDC

La bibliothèque Microsoft.AspNetCore.Components.WebAssembly.Authentication propose plusieurs primitives pour implémenter l’authentification et l’autorisation à l’aide d’OIDC. Globalement, voici comment fonctionne l’authentification :

• Lorsqu’un utilisateur anonyme sélectionne le bouton de connexion ou demande un composant ou une page Razor avec l’[Authorize]attribut appliqué, l’utilisateur est redirigé vers la page de connexion de l’application (/authentication/login).
• Dans la page de connexion, la bibliothèque d’authentification prépare une redirection vers le point de terminaison d’autorisation. Le point de terminaison d’autorisation se trouvant en dehors de l’application Blazor WebAssembly, il peut être hébergé séparément à une autre origine. Le point de terminaison est chargé de déterminer si l’utilisateur est authentifié et d’émettre un ou plusieurs jetons en réponse. La bibliothèque d’authentification fournit un rappel de connexion pour recevoir la réponse d’authentification.
  • Si l’utilisateur n’est pas authentifié, l’utilisateur est redirigé vers le système d’authentification sous-jacent, qui est généralement ASP.NET Core Identity.
  • Si l’utilisateur a déjà été authentifié, le point de terminaison d’autorisation génère les jetons appropriés et redirige le navigateur vers le point de terminaison de rappel de connexion (/authentication/login-callback).
• Quand l’application Blazor WebAssembly charge le point de terminaison de rappel de connexion (/authentication/login-callback), la réponse d’authentification est traitée.
  • Si le processus d’authentification arrive à son terme, l’utilisateur est authentifié et éventuellement renvoyé à l’URL protégée initialement demandée par l’utilisateur.
  • Si le processus d’authentification échoue pour une raison quelconque, l’utilisateur est envoyé à la page d’échec de connexion (/authentication/login-failed), et une erreur s’affiche.

Composant Authentication

Le composant Authentication (Authentication.razor) gère les opérations d’authentification à distance et permet à l’application de :

• Configurer les routes d’application pour les états d’authentification.
• Définir le contenu de l’interface utilisateur pour les états d’authentification.
• Gérer les clés d’authentification.

Les actions d’authentification, telles que l’inscription ou la connexion d’un utilisateur, sont transmises au composant Blazor du framework RemoteAuthenticatorViewCore<TAuthenticationState>, qui conserve et contrôle l’état lors des différentes opérations d’authentification.

Pour obtenir des informations et des exemples supplémentaires, consultez Autres scénarios de sécurité ASP.NET Core Blazor WebAssembly.

Autorisation

Dans les applications Blazor WebAssembly, les contrôles d’autorisation peuvent être contournés, car tout le code côté client peut être modifié par les utilisateurs. Cela vaut également pour toutes les technologies d’application côté client, y compris les infrastructures d’application JavaScript SPA ou les applications natives pour n’importe quel système d’exploitation.

Effectuez toujours les vérifications d’autorisation sur le serveur au sein des points de terminaison de l’API auxquels votre application côté client accède.

Personnaliser l’authentification

Blazor WebAssembly fournit des méthodes permettant d’ajouter et de récupérer des paramètres supplémentaires pour la bibliothèque d’authentification sous-jacente, afin d’effectuer des opérations d’authentification à distance avec des fournisseurs d’identity externes.

Pour passer des paramètres supplémentaires, NavigationManager prend en charge le passage et la récupération de l’état des entrées de l’historique lors de modifications d’emplacement externe. Pour plus d’informations, consultez les ressources suivantes :

• BlazorFondamentaux>Article Routage et navigation
  • État de l’historique de navigation
  • Options de navigation
• Documentation MDN : API Historique

L’état stocké par l’API Historique offre les avantages suivants pour l’authentification à distance :

• L’état passé au point de terminaison de l’application sécurisée est lié à la navigation effectuée pour authentifier l’utilisateur au niveau du point de terminaison authentication/login.
• L’encodage et le décodage supplémentaires des données sont évités.
• Les vulnérabilités sont réduites. Contrairement à l’utilisation de la chaîne de requête pour stocker l’état de navigation, une navigation de niveau supérieur ou une influence à partir d’une autre origine ne peut pas définir l’état stocké par l’API Historique.
• L’entrée de l’historique est remplacée après une authentification réussie : l’état attaché à l’entrée de l’historique est donc supprimé et ne nécessite pas de nettoyage.

InteractiveRequestOptions représente la demande adressée au fournisseur d’identity pour la connexion ou l’approvisionnement d’un jeton d’accès.

NavigationManagerExtensions fournit la méthode NavigateToLogin pour une opération de connexion et NavigateToLogout pour une opération de déconnexion. Les méthodes appellent NavigationManager.NavigateTo, en définissant l’état de l’entrée de l’historique avec un InteractiveRequestOptions passé ou une nouvelle instance de InteractiveRequestOptions créée par la méthode pour :

• Un utilisateur se connecte (InteractionType.SignIn) avec l’URI actuel pour l’URL de retour.
• Un utilisateur se déconnecte (InteractionType.SignOut) avec l’URL de retour.

Les scénarios d’authentification suivants sont abordés dans l’article Scénarios de sécurité supplémentaires de Blazor WebAssembly d’ASP.NET Core :

• Personnaliser le processus de connexion
• Se déconnecter avec une URL de retour personnalisée
• Personnaliser les options avant d’obtenir un jeton de façon interactive
• Personnaliser les options lors de l’utilisation d’un IAccessTokenProvider
• Obtenir le chemin de connexion à partir des options d’authentification

Exiger une autorisation pour l’application entière

Appliquez l’attribut [Authorize] (documentation de l’API) à chaque composant Razor de l’application en utilisant l’une des approches suivantes :

• Dans le fichier Imports de l’application, ajoutez une directive @using pour l’espace de noms Microsoft.AspNetCore.Authorization avec une directive @attribute pour l’attribut [Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Autorisez l’accès anonyme au composant Authentication pour autoriser la redirection vers le fournisseur d’identity. Ajoutez le code Razor suivant au composant Authentication sous sa directive @page.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Ajoutez l’attribut à chaque composant Razor sous la directive @page :

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Remarque

Le fait de définir une stratégie pour AuthorizationOptions.FallbackPolicy avec RequireAuthenticatedUser n’est pas pris en charge.

Utiliser une inscription d’application de fournisseur d’identity par application

Certains des articles sous cette vue d’ensemble concernent des scénarios d’hébergement Blazor qui impliquent deux applications ou plus. Une application Blazor WebAssembly autonome utilise l’API web avec des utilisateurs authentifiés pour accéder aux ressources du serveur et aux données fournies par une application serveur.

Lorsque ce scénario est implémenté dans des exemples de documentation, deux inscriptions de fournisseur d’identity sont utilisées, l’une pour l’application cliente et l’autre pour l’application serveur. L’utilisation d’inscriptions distinctes n’est pas strictement nécessaire, par exemple dans l’ID Microsoft Entra. Toutefois, l’utilisation de deux inscriptions est une bonne pratique de sécurité, car elle isole les inscriptions par application. L’utilisation d’inscriptions distinctes permet également une configuration indépendante des inscriptions client et serveur.

Jetons d’actualisation

Bien que les jetons d’actualisation ne puissent pas être sécurisés dans les applications Blazor WebAssembly, ils peuvent être utilisés si vous les implémentez avec des stratégies de sécurité appropriées.

Pour les applications autonomes Blazor WebAssembly dans ASP.NET Core dans .NET 6 ou version ultérieure, nous vous recommandons d’utiliser :

• Flux de code d’autorisation OAuth 2.0 (code) avec une clé de preuve pour l’échange de code (PKCE).
• Jeton d’actualisation dont l’expiration est courte.
• Jeton d’actualisation pivoté.
• Jeton d’actualisation avec une expiration après laquelle un nouveau flux d’autorisation interactif est nécessaire pour actualiser les informations d’identification de l’utilisateur.

Pour plus d’informations, consultez les ressources suivantes :

• Jetons d’actualisation de la plateforme d’identity Microsoft : durée de vie du jeton d’actualisation
• OAuth 2.0 pour les applications basées sur un navigateur (spécification IETF)

Établir des revendications pour les utilisateurs

Les applications nécessitent souvent des revendications pour les utilisateurs reposant sur un appel d’API web à destination d’un serveur. Par exemple, les revendications sont souvent utilisées pour établir une autorisation dans une application. Dans ces scénarios, l’application demande un jeton d’accès pour accéder au service et se sert du jeton pour obtenir les données utilisateur pour la création de revendications.

Pour des exemples, consultez les ressources suivantes :

• Autres scénarios : Personnaliser l’utilisateur
• ASP.NET Core Blazor WebAssembly avec des groupes et des rôles ID Microsoft Entra

Prise en charge du prerendering

Le prérendu (« prerendering » en anglais) n’est pas pris en charge pour les points de terminaison d’authentification (segment de chemin /authentication/).

Pour plus d’informations, consultez Autres scénarios de sécurité ASP.NET Core Blazor WebAssembly.

Azure App Service sur Linux avec Identity Server

Spécifiez explicitement l’émetteur quand le déploiement a pour cible Azure App Service sur Linux avec Identity Server.

Pour plus d’informations, consultez Utiliser Identity pour sécuriser un back-end d’API web pour des applications monopage.

Authentification Windows

Nous vous déconseillons d’utiliser l’authentification Windows avec Blazor Webassembly ou tout autre framework SPA. À la place de l’authentification Windows, nous vous recommandons d’utiliser des protocoles basés sur des jetons, comme OIDC avec les services de fédération Active Directory (AD FS).

Si l’authentification Windows est utilisée avec Blazor Webassembly ou avec n’importe quel autre framework SPA, des mesures supplémentaires sont nécessaires pour protéger l’application contre les jetons de falsification de requête intersite (CSRF). Les inquiétudes qui s’appliquent aux cookies valent aussi pour l’authentification Windows avec en outre le fait que cette dernière n’offre aucun mécanisme pour empêcher le partage du contexte d’authentification entre les origines. Les applications qui utilisent l’authentification Windows sans une protection supplémentaire contre les jetons CSRF doivent au moins être limitées à l’intranet d’une organisation et ne pas être utilisées sur Internet.

Pour plus d’informations, consultez Prévenir les attaques par falsification de requête intersites (XSRF/CSRF) dans ASP.NET Core.

Sécuriser un hub SignalR

Pour sécuriser un hub SignalR dans le projet d’API serveur, appliquez l’attribut [Authorize] à la classe hub ou aux méthodes de la classe hub.

Dans un projet client avec un prérendu, tel que Blazor WebAssembly hébergé (ASP.NET Core dans .NET 7 ou une version antérieure) ou une Blazor Web App (ASP.NET Core dans .NET 8 ou une version ultérieure), consultez les instructions dans l’aide BlazorSignalR ASP.NET Core.

Dans un composant de projet client sans prérendu, tel que Blazor WebAssembly autonome ou les applications non-navigateurs, fournissez un jeton d’accès à la connexion hub, comme l’illustre l’exemple suivant. Pour plus d’informations, consultez Authentification et autorisation dans ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Journalisation

Cette section s’applique aux applications Blazor WebAssembly dans ASP.NET Core dans .NET 7 ou version ultérieure.

Pour activer la journalisation de débogage ou de suivi, consultez la section Journalisation de l’authentification (Blazor WebAssembly) dans une version 7.0 ou ultérieure de l’article de journalisation ASP.NET CoreBlazor.

Bac à sable WebAssembly

Le bac à sable WebAssembly limite l’accès à l’environnement du système exécutant du code WebAssembly, y compris l’accès aux sous-systèmes d’E/S, au stockage système et aux ressources, ainsi qu’au système d’exploitation. L’isolation entre le code WebAssembly et le système qui exécute le code fait de WebAssembly une infrastructure de codage sécurisée pour les systèmes. Toutefois, WebAssembly est vulnérable aux attaques par canal latéral au niveau du matériel. Des précautions normales et une diligence raisonnable dans l’approvisionnement en matériel et en plaçant des limitations sur l’accès au matériel s’appliquent.

WebAssembly n’est pas détenu ou géré par Microsoft.

Pour plus d’informations, consultez les ressources W3C suivantes :

• WebAssembly : Sécurité
• Spécification WebAssembly : Considérations relatives à la sécurité
• W3C WebAssembly Community Group : commentaires et problèmes : le lien W3C WebAssembly Community Group est fourni uniquement à titre de référence, ce qui indique clairement que les vulnérabilités et bogues de sécurité WebAssembly sont corrigés en continu, souvent signalés et traités par le navigateur. N’envoyez pas de commentaires ou de rapports de bogues Blazor au W3C WebAssembly Community Group.Blazor les commentaires doivent être signalés à l’unité de produit Microsoft ASP.NET Core. Si l’unité de produit Microsoft détermine qu’il existe un problème sous-jacent avec WebAssembly, elle prend les mesures appropriées pour signaler le problème au groupe de la communauté WebAssembly W3C.

Conseils de mise en œuvre

Les articles de cette Vue d’ensemble fournissent des informations sur l’authentification des utilisateurs dans les applications Blazor WebAssembly auprès de certains fournisseurs.

Applications Blazor WebAssembly autonomes :

• Aide générale pour les fournisseurs OIDC et la bibliothèque d’authentification WebAssembly
• Comptes Microsoft
• ID Microsoft Entra (ME-ID)
• Azure Active Directory (AAD) B2C

Vous trouverez une aide supplémentaire pour la configuration dans les articles suivants :

• Autres scénarios de sécurité ASP.NET Core Blazor WebAssembly
• Utiliser l’API Graph avec ASP.NET Core Blazor WebAssembly

Utiliser le flux de code d’autorisation avec PKCE (Proof Key for Code Exchange)

La bibliothèque d’authentification Microsoft pour JavaScript (MSAL) v2.0 ou ultérieure, de la Plateforme d’identity Microsoft prend en charge le flux de code d’autorisation avec la clé de preuve pour l’échange de code (PKCE) et le partage des ressources cross-origin (CORS) pour les applications monopages, dont Blazor.

Microsoft ne recommande pas l’utilisation de l’octroi implicite.

Pour plus d’informations, consultez les ressources suivantes :

• Prise en charge du flux d’authentification dans MSAL : octroi implicite
• Plateforme d’identity Microsoft et flux d’octroi implicite : préférer le flux de code d’authentification
• Plateforme d’identity Microsoft et flux de code d’autorisation OAuth 2.0

Ressources supplémentaires

• Documentation de la plateforme d’identity Microsoft
  • Documentation générale
  • Jetons d’accès
• Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge
  • 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.
• Prérendu avec authentification
• WebAssembly : Sécurité
• Spécification WebAssembly : Considérations relatives à la sécurité