Applications Blazor sécurisées côté serveur ASP.NET Core

Cet article explique comment sécuriser les applications Blazor côté serveur en tant qu'applications ASP.NET Core.

Les applications Blazor côté serveur sont configurées pour la sécurité de la même manière que les applications ASP.NET Core. Pour plus d’informations, consultez les articles relevant des rubriques de sécurité ASP.NET Core.

Le contexte d'authentification n'est établi qu'au démarrage de l'application, c'est-à-dire lorsque l'application se connecte pour la première fois au WebSocket. Le contexte d’authentification est conservé pendant toute la durée de vie du circuit. Les applications revalident périodiquement l'état d'authentification de l'utilisateur, actuellement toutes les 30 minutes par défaut.

Si l’application doit capturer des utilisateurs pour des services personnalisés ou réagir aux mises à jour de l’utilisateur, consultez Scénarios de sécurité supplémentaires ASP.NET Core Blazor côté serveur.

Blazor diffère d’une application web rendue sur serveur traditionnelle qui effectue de nouvelles requêtes HTTP avec des cookie sur chaque navigation de page. L’authentification est vérifiée pendant les événements de navigation. Toutefois, les cookie ne sont pas impliqués. Les Cookie sont envoyés uniquement lors de l’envoi d’une requête HTTP à un serveur, ce qui n’est pas le cas lorsque l’utilisateur navigue dans une application Blazor. Pendant la navigation, l’état d’authentification de l’utilisateur est vérifié dans le circuit Blazor, que vous pouvez mettre à jour à tout moment sur le serveur à l’aide de l’RevalidatingAuthenticationStateProviderabstraction.

Important

La mise en œuvre d'une personnalisation NavigationManager pour obtenir la validation de l'authentification pendant la navigation n'est pas recommandée. Si l’application doit exécuter une logique d’état d’authentification personnalisée pendant la navigation, utilisez un personnalisé AuthenticationStateProvider.

Remarque

Les exemples de code de cet article utilisent les types de référence null (NRT, nullable reference types) et l'analyse statique de l'état null du compilateur .NET, qui sont pris en charge dans ASP.NET Core 6 et ses versions ultérieures. Lorsque vous ciblez ASP.NET Core 5.0 ou version antérieure, supprimez la désignation de type null (?) des exemples de cet article.

Modèle de projet

Créez une nouvelle application côté serveur Blazor en suivant les instructions de la section Outils pour ASP.NET Core Blazor.

Visual Studio

Après avoir choisi le modèle d'application côté serveur et configuré le projet, sélectionnez l'authentification de l'application sous Type d'authentification :

• Aucun (valeur par défaut) : aucune authentification.
• Comptes individuels : les comptes d’utilisateur sont stockés dans l’application à l’aide d’ASP.NET Core Identity.

Visual Studio Code

Lorsque vous exécutez la commande .NET CLI pour créer et configurer l'application côté serveur Blazor, indiquez le mécanisme d'authentification avec l'option -au|--auth :

-au {AUTHENTICATION}

Remarque

Pour obtenir la commande complète, consultez Outils pour ASP.NET Core Blazor.

Les valeurs d’authentification autorisées pour l’espace réservé {AUTHENTICATION} sont indiquées dans le tableau suivant.

Mécanisme d’authentification	Description
None (valeur par défaut)	Aucune authentification
Individual	Utilisateurs stockés dans l’application avec ASP.NET Core Identity

Pour plus d’informations, consultez la commande dotnet new dans le guide .NET Core.

CLI .NET Core

Lorsque vous exécutez la commande .NET CLI pour créer et configurer l'application côté serveur Blazor, indiquez le mécanisme d'authentification avec l'option -au|--auth :

-au {AUTHENTICATION}

Remarque

Pour obtenir la commande complète, consultez Outils pour ASP.NET Core Blazor.

Les valeurs d’authentification autorisées pour l’espace réservé {AUTHENTICATION} sont indiquées dans le tableau suivant.

Mécanisme d’authentification	Description
None (valeur par défaut)	Aucune authentification
Individual	Utilisateurs stockés dans l’application avec ASP.NET Core Identity

Pour plus d'informations :

• Consultez la commande dotnet new dans le guide .NET Core.

• Exécutez la commande d'aide pour le modèle dans un shell de commande :

  dotnet new {PROJECT TEMPLATE} --help
  

  Dans la commande précédente, l'espace réservé {PROJECT TEMPLATE} est le modèle de projet.

Interface utilisateur BlazorIdentity (comptes individuels)

Blazor prend en charge la génération d’une interface utilisateur complète basée sur Blazor de Identity lorsque vous choisissez l’option d’authentification Comptes individuels.

Le modèle Web App Blazor échafaude le code Identity d’une base de données SQL Server. La version en ligne de commande utilise SQLite par défaut et inclut une base de données SQLite pour Identity.

Le modèle gère les éléments suivants :

• Ajoute des composants IdentityRazor et une logique associée pour les tâches d’authentification de routine, telles que la connexion et la déconnexion des utilisateurs.
  • Les composants Identity prennent également en charge les fonctionnalités avancées Identity, telles que la confirmation de compte et la récupération de mot de passe et l’authentification multifacteur à l’aide d’une application tierce.
  • Les scénarios de rendu côté serveur interactif (SSR interactif) et de rendu côté client (CSR) sont pris en charge.
• Ajoute les packages et dépendances associés à Identity.
• Référence les packages Identity dans _Imports.razor.
• Crée une classe Identity d’utilisateur personnalisée (ApplicationUser).
• Crée et inscrit un contexte de base de données EF Core (ApplicationDbContext).
• Configure le routage pour les points de terminaison Identity intégrés.
• Inclut la validation Identity et la logique métier.

Pour inspecter les composants Identity du framework Blazor, accédez-y dans les dossiers Pages et Shared du dossier Account dans le modèle de projet Application web Blazor (source de référence).

Lorsque vous choisissez les modes de rendu Interactive WebAssembly ou Interactive Auro, le serveur gère toutes les requêtes d’authentification et d’autorisation, et les composants Identity sont rendus de façon statique sur le serveur dans le projet principal de l’application web Blazor. Le modèle de projet inclut une classe PersistentAuthenticationStateProvider (source de référence) dans le projet .Client pour synchroniser l’état d’authentification de l’utilisateur entre le serveur et le navigateur. La classe est une implémentation personnalisée de AuthenticationStateProvider. Le fournisseur utilise la classe PersistentComponentState pour prédéfinir l’état d’authentification et le conserver sur la page.

BlazorIdentity dépend des instances DbContext qui ne sont pas créées par une fabrique, ce qui est intentionnel parce que DbContext suffit pour que les composants Identity du modèle de projet soient rendus de façon statique sans prendre en charge l’interactivité.

Dans le projet principal d’une application web Blazor, le fournisseur d’état d’authentification est nommé IdentityRevalidatingAuthenticationStateProvider (source de référence) (solutions d’interactivité de serveur uniquement) ou PersistingRevalidatingAuthenticationStateProvider (source de référence) (solutions d’interactivité WebAssembly ou automatique).

Pour obtenir une description de la façon dont les modes de rendu interactif globaux sont appliqués aux non-composantsIdentity tout en appliquant le SSR statique pour les Identity composants, consultez ASP.NET modesBlazor de rendu Core.

Pour plus d’informations sur la persistance de l’état pré-rendu, consultez Pré-rendre les composants Razor ASP.NET Core.

Pour plus d’informations sur l’interface utilisateur BlazorIdentity et des conseils sur l’intégration de connexions externes via des sites web sociaux, consultez Nouveautés de l’identité dans .NET 8.

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).

Gérer l’état de l’authentification dans les Web Apps Blazor

Cette section s’applique aux Web Apps Blazor qui adoptent :

• Rendu côté serveur interactif (SSR interactif) et rendu côté client (CSR).
• Rendu côté client (CSR).

Un fournisseur d’état de l’authentification côté client est utilisé uniquement dans Blazor et n’est pas intégré au système d’authentification ASP.NET Core. Lors de la prérendu, Blazor respecte les métadonnées définies sur la page et utilise le système d’authentification ASP.NET Core pour déterminer si l’utilisateur est authentifié. Lorsqu’un utilisateur va d’une page à une autre, un fournisseur d’authentification côté client est utilisé. Lorsque l’utilisateur actualise la page (actualisation complète de la page), le fournisseur d’état de l’authentification côté client n’est pas impliqué dans la décision d’authentification sur le serveur. L’état de l’utilisateur n’étant pas conservé par le serveur, tout état d’authentification géré côté client est perdu.

Pour résoudre ce problème, la meilleure approche consiste à effectuer l’authentification dans le système d’authentification ASP.NET Core. Le fournisseur d’état de l’authentification côté client ne se charge que de refléter l’état d’authentification de l’utilisateur. Les exemples d’utilisation des fournisseurs d’état d’authentification sont illustrés par le modèle de projet Web App Blazor :

• PersistingRevalidatingAuthenticationStateProvider (source de référence) : Pour Web Apps Blazor qui adoptent le rendu côté serveur interactif (SSR interactif) et le rendu côté client (CSR). Il s’agit d’un AuthenticationStateProvider côté serveur qui revalide l’empreinte de sécurité de l’utilisateur connecté toutes les 30 minutes lorsqu’un circuit interactif est connecté. Il utilise également le service d’état du composant persistant pour transmettre l’état d’authentification au client. Ce dernier est ensuite fixe pour la durée de vie du rendu côté client (CSR).

• PersistingServerAuthenticationStateProvider (source de référence) : Pour Web Apps Blazor qui adoptent uniquement le rendu côté client (CSR). Il s’agit d’un AuthenticationStateProvider côté serveur qui utilise le service d’état du composant persistant pour transmettre l’état d’authentification au client. Ce dernier est ensuite fixe pour la durée de vie du rendu côté client (CSR).

• PersistentAuthenticationStateProvider (source de référence) : Pour Web Apps Blazor qui adoptent le rendu côté client (CSR). Il s’agit d’un AuthenticationStateProvider côté client qui détermine l’état d’authentification de l’utilisateur en recherchant les données persistantes dans la page, lorsqu’elles ont été rendues sur le serveur. Cet état d’authentification est fixe pour la durée de vie du rendu côté client (CSR). Si l’utilisateur doit se connecter ou se déconnecter, une actualisation complète de la page est nécessaire. Cela fournit uniquement un nom d’utilisateur et un e-mail à des fins d’affichage. Il n’inclut pas les jetons qui s’authentifient auprès du serveur lors de l’exécution de requêtes ultérieures. Ces dernières sont gérées séparément à l’aide d’un cookie, inclus dans les requêtes HttpClient envoyées au serveur.

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).

Revendications et jetons supplémentaires en provenance de fournisseurs externes

Pour stocker des revendications supplémentaires en provenance de fournisseurs externes, consultez Conserver les revendications et les jetons supplémentaires de fournisseurs externes dans ASP.NET Core.

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 les SPA.

Implémenter un AuthenticationStateProvider personnalisé

Si l’application nécessite un fournisseur personnalisé, implémentez AuthenticationStateProvider et remplacez GetAuthenticationStateAsync.

Dans l’exemple suivant, tous les utilisateurs sont authentifiés avec le nom d’utilisateur mrfibuli.

CustomAuthStateProvider.cs:

using System.Security.Claims;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.Authorization;

public class CustomAuthStateProvider : AuthenticationStateProvider
{
    public override Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        var identity = new ClaimsIdentity(new[]
        {
            new Claim(ClaimTypes.Name, "mrfibuli"),
        }, "Custom Authentication");

        var user = new ClaimsPrincipal(identity);

        return Task.FromResult(new AuthenticationState(user));
    }
}

Le service CustomAuthStateProvider est inscrit dans le ficher Program :

using Microsoft.AspNetCore.Components.Authorization;

...

builder.Services.AddScoped<AuthenticationStateProvider, CustomAuthStateProvider>();

Confirmez ou ajoutez un AuthorizeRouteView au composant Router.

Dans le composant Routes (Components/Routes.razor) :

<Router ...>
    <Found ...>
        <AuthorizeRouteView RouteData="routeData" 
            DefaultLayout="typeof(Layout.MainLayout)" />
        ...
    </Found>
</Router>

Ajoutez des services d’état d’authentification en cascade à la collection de services dans le fichier Program :

builder.Services.AddCascadingAuthenticationState();

Remarque

Lorsque vous créez une application Blazor à partir de l'un des modèles de projet Blazor avec l'authentification activée, l'application inclut AuthorizeRouteView et appelle AddCascadingAuthenticationState. Pour plus d’informations, consultez Authentification et autorisation Blazor ASP.NET Core avec des informations supplémentaires présentées dans la section Personnaliser le contenu non autorisé avec le composant Routeur de l’article.

Un AuthorizeView illustre le nom de l’utilisateur authentifié dans n’importe quel composant :

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

Pour obtenir des conseils sur l’utilisation de AuthorizeView, consultez Authentification et autorisation Blazor ASP.NET Core.

Notification sur les changements d’état de l’authentification

Un personnalisé AuthenticationStateProvider peut faire appel à NotifyAuthenticationStateChanged sur la classe de base AuthenticationStateProvider pour informer les consommateurs de la modification de l’état d’authentification en vue d’un nouveau rendu.

L’exemple suivant est basé sur l’implémentation d’une personnalisation AuthenticationStateProvider en suivant les instructions de la section Implémenter une personnalisation AuthenticationStateProvider.

L’implémentation suivante CustomAuthStateProvider expose une méthode personnalisée, AuthenticateUser, pour connecter un utilisateur et informer les consommateurs du changement d’état d’authentification.

CustomAuthStateProvider.cs:

using System.Security.Claims;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.Authorization;

public class CustomAuthStateProvider : AuthenticationStateProvider
{
    public override Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        var identity = new ClaimsIdentity();
        var user = new ClaimsPrincipal(identity);

        return Task.FromResult(new AuthenticationState(user));
    }

    public void AuthenticateUser(string userIdentifier)
    {
        var identity = new ClaimsIdentity(new[]
        {
            new Claim(ClaimTypes.Name, userIdentifier),
        }, "Custom Authentication");

        var user = new ClaimsPrincipal(identity);

        NotifyAuthenticationStateChanged(
            Task.FromResult(new AuthenticationState(user)));
    }
}

Dans un composant  :

• Injection du code AuthenticationStateProvider.
• Ajoutez un champ pour contenir l’identificateur d’utilisateur.
• Ajoutez un bouton et une méthode pour caster le AuthenticationStateProvider vers CustomAuthStateProvider et appeler AuthenticateUser avec l’identificateur d’utilisateur.

@inject AuthenticationStateProvider AuthenticationStateProvider

<input @bind="userIdentifier" />
<button @onclick="SignIn">Sign in</button>

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    public string userIdentifier = string.Empty;

    private void SignIn()
    {
        ((CustomAuthStateProvider)AuthenticationStateProvider)
            .AuthenticateUser(userIdentifier);
    }
}

L’approche précédente peut être améliorée pour déclencher des notifications de changements d’état d’authentification via un service personnalisé. Les éléments suivants AuthenticationService conservent le principal de revendications de l’utilisateur actuel dans un champ de stockage (currentUser) avec un événement (UserChanged) auquel le AuthenticationStateProvider peut s’abonner, où l’événement appelle NotifyAuthenticationStateChanged. Avec la configuration supplémentaire décrite plus loin dans cette section, le AuthenticationService peut être injecté dans un composant avec une logique qui définit le CurrentUser pour déclencher l’événement UserChanged.

using System.Security.Claims;

public class AuthenticationService
{
    public event Action<ClaimsPrincipal>? UserChanged;
    private ClaimsPrincipal? currentUser;

    public ClaimsPrincipal CurrentUser
    {
        get { return currentUser ?? new(); }
        set
        {
            currentUser = value;

            if (UserChanged is not null)
            {
                UserChanged(currentUser);
            }
        }
    }
}

Dans le fichier Program, enregistrez le AuthenticationService dans le conteneur d'injection de dépendances :

builder.Services.AddScoped<AuthenticationService>();

Les éléments suivants CustomAuthStateProvider s’abonnent à l’événement AuthenticationService.UserChanged. GetAuthenticationStateAsync retourne l’état d’authentification de l’utilisateur. Initialement, l’état d’authentification est basé sur la valeur de AuthenticationService.CurrentUser. En cas de modification de l’utilisateur, un nouvel état d’authentification est créé avec le nouvel utilisateur (new AuthenticationState(newUser)) pour les appels à GetAuthenticationStateAsync :

using System.Security.Claims;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.Authorization;

public class CustomAuthStateProvider : AuthenticationStateProvider
{
    private AuthenticationState authenticationState;

    public CustomAuthStateProvider(AuthenticationService service)
    {
        authenticationState = new AuthenticationState(service.CurrentUser);

        service.UserChanged += (newUser) =>
        {
            authenticationState = new AuthenticationState(newUser);

            NotifyAuthenticationStateChanged(
                Task.FromResult(new AuthenticationState(newUser)));
        };
    }

    public override Task<AuthenticationState> GetAuthenticationStateAsync() =>
        Task.FromResult(authenticationState);
}

La méthode SignIn du composant suivant crée un principal de revendications pour l’identificateur de l’utilisateur à définir sur AuthenticationService.CurrentUser :

@inject AuthenticationService AuthenticationService

<input @bind="userIdentifier" />
<button @onclick="SignIn">Sign in</button>

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    public string userIdentifier = string.Empty;

    private void SignIn()
    {
        var currentUser = AuthenticationService.CurrentUser;

        var identity = new ClaimsIdentity(
            new[]
            {
                new Claim(ClaimTypes.Name, userIdentifier),
            },
            "Custom Authentication");

        var newUser = new ClaimsPrincipal(identity);

        AuthenticationService.CurrentUser = newUser;
    }
}

Injectez AuthenticationStateProvider pour les services liés à un composant

N’essayez pas de résoudre AuthenticationStateProvider dans une étendue personnalisée, car cela entraîne la création d’une nouvelle instance du AuthenticationStateProvider qui n’est pas correctement initialisée.

Pour accéder au AuthenticationStateProvider dans un service délimité à un composant, injectez le AuthenticationStateProvider avec la @inject directive ou l’[Inject]attribut et passez-le au service en tant que paramètre. Cette approche garantit que l’instance correcte et initialisée du AuthenticationStateProvider est utilisée pour chaque instance d’application utilisateur.

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

Inscrivez le service comme délimité. Dans une application Blazor côté serveur, les services étendus ont une durée de vie égale à la durée du circuit de connexion client.

Dans le fichier Program :

builder.Services.AddScoped<ExampleService>();

Dans le composant InjectAuthStateProvider suivant :

• Le composant hérite OwningComponentBase.
• Le AuthenticationStateProvider est injecté et passé à ExampleService.ExampleMethod.
• ExampleService est résolu avec OwningComponentBase.ScopedServices et GetRequiredService, qui renvoie l’instance correcte et initialisée de ExampleService qui existe pendant la durée de vie du circuit de l’utilisateur.

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

Pour plus d’informations, consultez les conseils sur OwningComponentBase dans l’injection de dépendances Blazor dans ASP.NET Core.

Affichage de contenu non autorisé lors du prérendu avec un fichier personnalisé AuthenticationStateProvider

Pour éviter d’afficher du contenu non autorisé, par exemple pour un exemple de contenu dans un AuthorizeViewcomposant, lors d’un prérendu avec un AuthenticationStateProvider personnalisé, adoptez l’une des approches suivantes :

• Implémentation de IHostEnvironmentAuthenticationStateProvider pour que la personnalisation de AuthenticationStateProvider prenne en charge le prérendu : pour un exemple d'implémentation de IHostEnvironmentAuthenticationStateProvider, consultez l' Blazor implémentation du framework ServerAuthenticationStateProvider dans ServerAuthenticationStateProvider.cs (source de référence) .

  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).

• Désactiver le prérendu : indiquez le mode de rendu avec le paramètre prerender défini sur false au niveau le plus élevé dans la hiérarchie des composants de l’application qui n’est pas un composant racine.

  Remarque

  Rendre un composant racine interactif, comme le composant App, n’est pas pris en charge. Par conséquent, le prérendu ne peut pas être désactivé directement par le composant App.

  Pour les applications basées sur le modèle de projet d’application web Blazor, le prérendu est habituellement désactivé où le composant Routes est utilisé dans le composant App (Components/App.razor) :

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Désactivez également le pré-rendu pour le composant HeadOutlet :

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Vous pouvez également désactiver de manière sélective le prérendu avec un contrôle précis du mode de rendu appliqué à l’instance du composant Routes. Pour plus d’informations, consultez Modes de rendu ASP.NET Core Blazor.

• Authentifier l'utilisateur sur le serveur avant le démarrage de l'application : pour adopter cette approche, l'application doit répondre à la requête initiale d'un utilisateur avec la page de connexion basée sur Identity- ou afficher et empêcher toute demande adressée aux points de terminaison Blazor jusqu'à ce qu'ils soient authentifiés. Pour plus d’informations, consultez Créer une application ASP.NET Core avec des données utilisateur protégées par autorisation. Après l'authentification, le contenu non autorisé dans les composants Razor pré-rendus n'est affiché que lorsque l'utilisateur n'est réellement pas autorisé à afficher le contenu.

Gestion de l'état des utilisateurs

En dépit du mot « état » dans le nom, AuthenticationStateProvider n’est pas destiné au stockage de l’état général de l’utilisateur. AuthenticationStateProvider indique uniquement l’état d’authentification de l’utilisateur par rapport à l’application, s’il est connecté à l’application et sous quel nom il est connecté.

L'authentification utilise la même authentification Identity ASP.NET Core que les applications Pages Razor et MVC. L’état utilisateur stocké pour ASP.NET Core Identity transite vers Blazor sans ajouter de code supplémentaire à l’application. Suivez les instructions fournies dans les articles et tutoriels ASP.NET Core Identity pour que les fonctionnalités Identity prennent effet dans les parties Blazor de l’application.

Pour obtenir des conseils sur la gestion générale de l’état en dehors de ASP.NET Core Identity, consultez Gestion de l’état Blazor ASP.NET Core.

Abstractions de sécurité supplémentaires

Deux abstractions supplémentaires participent à la gestion de l’état d’authentification :

• ServerAuthenticationStateProvider (source de référence) : unAuthenticationStateProvider utilisé par l’infrastructure Blazor pour obtenir l’état d’authentification du serveur.

• RevalidatingServerAuthenticationStateProvider (source de référence) : une classe de base pour les services AuthenticationStateProvider utilisés par l’infrastructure Blazor pour recevoir un état d’authentification de l’environnement hôte et le revalider à intervalles réguliers.

  L'intervalle de revalidation par défaut de 30 minutes peut être ajusté dans RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs). L’exemple suivant raccourcit l’intervalle à 20 minutes :

  protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(20);
  

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).

Durée de validité de l’URL de redirection temporaire

Cette section s’applique aux applications web Blazor.

Utilisez l’option RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration pour obtenir ou définir la durée de vie de la validité de la protection des données pour les URL de redirection temporaires émises par le rendu côté serveur de Blazor. Celles-ci sont utilisés temporairement : la durée de vie doit donc être suffisamment longue pour qu’un client reçoive l’URL et commence la navigation vers celle-ci. Cependant, elle doit aussi être suffisamment longue pour tenir compte des décalages d’horloge entre les serveurs. La valeur par défaut est de cinq minutes.

Dans l’exemple suivant, la valeur est étendue à sept minutes :

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

Ressources supplémentaires

• Démarrage rapide : Ajouter la connexion avec Microsoft à une application web ASP.NET Core
• Démarrage rapide : Protéger une API Web ASP.NET Core avec la plateforme d'identités Microsoft
• 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.