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é :

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.

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]
  

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

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

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é