Autenticação e autorização do ASP.NET Core Blazor

Se a aplicação da regra de autorização precisar ser garantida, não implemente verificações de autorização no código do lado do cliente. Crie um Blazor Web App que confie unicamente na renderização do lado do servidor (SSR) para verificações de autorização e aplicação de regras.

Se a aplicação da regra de autorização e a segurança dos dados e do código precisarem ser garantidas, não desenvolva um aplicativo do lado do cliente. Crie um aplicativo Blazor Server.

ASP.NET Core Identity foi projetado para funcionar no contexto da comunicação de solicitação e resposta HTTP, que geralmente não é o modelo de comunicação cliente-servidor do aplicativo Blazor. Aplicações ASP.NET Core que utilizam o ASP.NET Core Identity para gestão de utilizadores devem usar Razor Páginas ao invés de componentes Razor para a interface do utilizador relacionada com Identity, como registo de utilizador, iniciar sessão, terminar sessão e outras tarefas de gestão de utilizadores. A criação de componentes Razor que lidam diretamente com Identity tarefas é possível para vários cenários, mas não é recomendada ou suportada pela Microsoft.

ASP.NET Abstrações principais, como SignInManager<TUser> e UserManager<TUser>, não são suportadas em componentes Razor. Para obter mais informações sobre como usar o ASP.NET Core Identity com Blazor, consulte Scaffold ASP.NET Core Identity num aplicativo Blazor do lado do servidor.

Suporte antifalsificação

O modelo Blazor:

• Adiciona serviços antifalsificação automaticamente quando AddRazorComponents é chamado no arquivo Program.
• Adiciona o Antiforgery Middleware chamando UseAntiforgery na sua pipeline de processamento de pedidos no arquivo Program e requisita proteção antifalsificação no endpoint com para mitigar as ameaças de falsificação de pedidos entre sites (CSRF/XSRF). UseAntiforgery é chamado após UseHttpsRedirection. Uma chamada para UseAntiforgery deve ser feita após chamadas, se houver, para UseAuthentication e UseAuthorization.

O componente AntiforgeryToken renderiza um token antifalsificação como um campo oculto, e esse componente é adicionado automaticamente às instâncias de formulário (EditForm). Para obter mais informações, consulte Visão geral ASP.NET formulários principaisBlazor.

O serviço AntiforgeryStateProvider fornece acesso a um token antifalsificação associado à sessão atual. Injete o serviço e chame o seu método GetAntiforgeryToken() para obter o AntiforgeryRequestToken atual. Para mais informações, consulte Chamar uma API da Web a partir de uma aplicação ASP.NET Core Blazor.

Blazor armazena tokens de solicitação no estado do componente, o que garante que os tokens antifalsificação estejam disponíveis para componentes interativos, mesmo quando eles não têm acesso à solicitação.

Para obter mais informações, consulte os seguintes recursos:

• Prevenir ataques de falsificação de solicitação entre sites (XSRF/CSRF) em ASP.NET Core: Este artigo é o principal sobre ASP.NET Core no assunto, que se aplica ao Blazor Server do lado do servidor, ao projeto de servidor de Blazor Web Apps e à integração de Blazor com páginas MVC/Razor.
• ASP.NET Core Visão geral dos formulários: A secção de suporte a antifalsificação do artigo refere-se ao suporte antifalsificação de formulários .

Blazor Identity UI (Contas Individuais)

Quando se escolhe a opção de autenticação para Blazor, Blazor suporta a geração de uma interface do usuário completa baseada em Identity.

O modelo Blazor Web App serve de estrutura para o código Identity de um banco de dados de SQL Server. A versão de linha de comando usa SQLite e inclui um banco de dados SQLite para Identity.

O modelo:

• Suporta cenários interativos de renderização do lado do servidor (SSR interativo) e CSR (renderização do lado do cliente) com usuários autenticados.
• Adiciona IdentityRazor componentes e lógica relacionada para tarefas de autenticação de rotina, como entrar e sair de usuários. Os Identity componentes também suportam recursos avançados Identity , como confirmação de conta e recuperação de senha e autenticação multifator usando um aplicativo de terceiros. Observe que os próprios componentes Identity não suportam interatividade.
• Adiciona os pacotes e dependências relacionados ao Identity.
• Faz referência aos pacotes Identity em _Imports.razor.
• Cria uma classe de usuário Identity personalizada (ApplicationUser).
• Cria e registra um contexto de banco de dados EF Core (ApplicationDbContext).
• Configura o roteamento para as extremidades integradas de Identity.
• Inclui validação Identity e lógica de negócios.

Para inspecionar os componentes da estrutura do , aceda-os nas pastas e da pasta no projeto de servidor do modelo de projeto ( repositório GitHub).

Quando você escolhe os modos de renderização Interactive WebAssembly ou Interactive Auto, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity renderizam estaticamente no servidor no projeto principal do Blazor Web App.

O framework fornece uma AuthenticationStateProvider personalizada nos projetos de servidor e cliente (.Client) de modo a transmitir o estado de autenticação do utilizador para o navegador. O projeto de servidor chama AddAuthenticationStateSerialization, enquanto o projeto cliente chama AddAuthenticationStateDeserialization. A autenticação no servidor em vez do cliente permite que o aplicativo acesse o estado de autenticação durante a pré-renderização e antes que o tempo de execução do .NET WebAssembly seja inicializado. As implementações personalizadas de AuthenticationStateProvider usam o serviço de Estado de Componente Persistente (PersistentComponentState) para serializar o estado de autenticação em comentários HTML e para depois lê-lo de volta do WebAssembly, criando assim uma nova instância de AuthenticationState. Para obter mais informações, consulte a seção Gerenciar estado de autenticação em Blazor Web Apps .

Somente para soluções de Servidor Interativo, IdentityRevalidatingAuthenticationStateProvider (Components/Account/IdentityRevalidatingAuthenticationStateProvider.cs) no projeto de servidor do modelo de projeto Blazor Web App (dotnet/aspnetcore repositório GitHub) é um componente do lado do servidor AuthenticationStateProvider que revalida o carimbo de segurança para o usuário conectado a cada 30 minutos enquanto o circuito interativo está conectado.

Quando você escolhe os modos de renderização Interactive WebAssembly ou Interactive Auto, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity renderizam estaticamente no servidor no projeto principal do Blazor Web App. O modelo de projeto inclui uma classe (fonte de referência) no projeto para sincronizar o estado de autenticação do utilizador entre o servidor e o navegador. A classe é uma implementação personalizada de AuthenticationStateProvider. O provedor usa o serviço de Estado Persistente do Componente (PersistentComponentState) para pré-renderizar o estado de autenticação e preservá-lo na página.

No projeto principal de um Blazor Web App, o provedor de estado de autenticação é nomeado IdentityRevalidatingAuthenticationStateProvider no diretório Components/Account do projeto de servidor no modelo de projeto Blazor Web App (dotnet/aspnetcore repositório GitHub) (aplicável apenas a soluções de interatividade do servidor) ou como PersistingRevalidatingAuthenticationStateProvider para soluções de interatividade WebAssembly ou Automática, no mesmo diretório.

Blazor Identity depende de DbContext instâncias não criadas por uma fábrica, o que é intencional porque DbContext é suficiente para que os Identity componentes do modelo de projeto sejam renderizados estaticamente sem oferecer suporte à interatividade.

Para obter uma descrição sobre como os modos de renderização interativos globais são aplicados a componentes nãoIdentity e, ao mesmo tempo, impõem SSR estático para os componentes Identity, consulte modos de renderização do ASP.NET Core Blazor.

Para obter mais informações sobre a persistência do estado pré-renderizado, consulte ASP.NET Persistência Blazor do estado pré-renderizado do núcleo.

Gerenciar o estado de autenticação no Blazor Web Apps

Esta secção aplica-se aos Blazor Web Appque adotam:

• Contas individuais
• Renderização do lado do cliente (CSR, interatividade suportada por WebAssembly).

Um provedor de estado de autenticação do lado do cliente é usado apenas dentro do Blazor e não está integrado ao sistema de autenticação ASP.NET Core. Durante a pré-renderização, Blazor respeita os metadados definidos na página e usa o sistema de autenticação ASP.NET Core para determinar se o usuário está autenticado. Quando um usuário navega de uma página para outra, um provedor de autenticação do lado do cliente é usado. Quando o usuário atualiza a página (recarga de página inteira), o provedor de estado de autenticação do lado do cliente não está envolvido na decisão de autenticação no servidor. Como o estado do usuário não é persistido pelo servidor, qualquer estado de autenticação mantido no lado do cliente é perdido.

Para resolver isso, a melhor abordagem é executar a autenticação dentro do sistema de autenticação ASP.NET Core. O provedor de estado de autenticação do lado do cliente cuida apenas de refletir o estado de autenticação do usuário. Exemplos de como fazer isso com provedores de estado de autenticação são demonstrados pelo modelo de projeto Blazor Web App e descritos abaixo.

No ficheiro do projeto de servidor, chame , que serializa o retornado pelo do lado do servidor utilizando o serviço de Estado Persistente do Componente ():

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

A API serializa apenas o nome do lado do servidor e as declarações de função para acesso no navegador. Para incluir todas as declarações, defina SerializeAllClaims como true na chamada do lado do servidor para AddAuthenticationStateSerialization:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

No arquivo .Client do projeto cliente (Program), chame AddAuthenticationStateDeserialization, que adiciona um AuthenticationStateProvider onde o AuthenticationState é desserializado do servidor usando AuthenticationStateData e o serviço de Estado de Componente Persistente (PersistentComponentState). Deve haver uma chamada correspondente para AddAuthenticationStateSerialization no projeto de servidor.

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

• PersistingRevalidatingAuthenticationStateProvider dotnet/aspnetcore(repositório GitHub): Para Blazor Web Apps que adotam renderização interativa do lado do servidor (SSR interativo) e renderização do lado do cliente (CSR). Este é um AuthenticationStateProvider do lado do servidor que revalida o carimbo de segurança para o utilizador conectado a cada 30 minutos em que um circuito interativo está conectado. Ele também utiliza o serviço de Estado do Componente Persistente para transferir o estado de autenticação para o cliente, que é então fixo durante toda a duração da CSR.

• PersistingServerAuthenticationStateProvider dotnet/aspnetcore(repositório GitHub): Para Blazor Web Apps que adotam apenas CSR. Este é um AuthenticationStateProvider do lado do servidor que usa o serviço de Estado Persistente do Componente para transferir o estado de autenticação para o cliente, que é então fixado durante toda a duração do CSR.

• PersistentAuthenticationStateProvider (dotnet/aspnetcore repositório GitHub): Para Blazor Web Apps que adotam CSR. Este é um AuthenticationStateProvider do lado do cliente que determina o estado de autenticação do utilizador, procurando dados persistidos na página quando esta foi renderizada no servidor. Este estado de autenticação é fixo durante a duração do CSR. Se o usuário precisar fazer login ou logout, será necessário um recarregamento de página inteira. Isso fornece apenas um nome de usuário e e-mail para fins de exibição. Não inclui tokens para autenticação no servidor ao fazer pedidos subsequentes; isso é tratado separadamente usando um cookie incluído em pedidos HttpClient para o servidor.

Andaime Identity

Para obter mais informações sobre scaffolding Identity num aplicativo do lado do servidor Blazor, consulte Scaffolding Identity em projetos ASP.NET Core.

Scaffold Identity num aplicativo Blazor do lado do servidor:

• Sem autorização existente.
• Com autorização.

No ficheiro Program:

builder.Services.AddScoped<ExampleService>();

Em Startup.ConfigureServices de Startup.cs:

services.AddScoped<ExampleService>();

@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);
    }
}

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

<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);
    }
}

• Desativar pré-renderização: indique o modo de renderização com o parâmetro prerender definido como false no componente de nível mais alto na hierarquia de componentes do aplicativo que não seja um componente raiz.

  Note

  Não há suporte para tornar um componente raiz interativo, como o componente App. Portanto, a pré-renderização não pode ser desabilitada diretamente pelo componente App.

  Para aplicativos baseados no modelo de projeto Blazor Web App, a pré-renderização normalmente é desabilitada quando o componente Routes é usado no componente App (Components/App.razor) :

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

  Além disso, desative a pré-renderização para o componente HeadOutlet:

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

  Você também pode controlar seletivamente o modo de renderização aplicado à instância do componente Routes. Por exemplo, consulte os modos de renderização do ASP.NET Core Blazor.

• Desativar a pré-renderização: abra o _Host.cshtml arquivo e altere o render-mode atributo do Component Tag Helper para Server:

  <component type="typeof(App)" render-mode="Server" />
  

Duração da validade do URL de redirecionamento temporário

Esta secção aplica-se a Blazor Web Apps.

Use a opção RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration para obter ou definir o tempo de vida da validade do ASP.NET Core Data Protection para URLs de redirecionamento temporário emitidas pela renderização do lado do servidor Blazor. Eles são usados apenas transitoriamente, então o tempo de vida só precisa ser longo o suficiente para que um cliente receba a URL e comece a navegação para ela. No entanto, ele também deve ser longo o suficiente para permitir o desvio do relógio entre servidores. O valor padrão é cinco minutos.

No exemplo a seguir, o valor é estendido para sete minutos:

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

Proteja os dados em Blazor Web App com renderização interativa automática

Quando um Blazor Web App adota a renderização do lado do servidor (SSR) e a renderização do lado do cliente (CSR) para componentes ou um aplicativo inteiro que especifica o modo de renderização automática interativa, a autorização para acessar componentes e dados é aplicada em dois locais. O componente restringe o acesso a si mesmo (e a quaisquer dados que obtenha) quando processado no servidor em virtude de um atributo de autorização no arquivo de definição do componente (@attribute [Authorize]). Quando o componente é renderizado no cliente, o acesso aos dados é restrito através dos endpoints da API web do servidor chamados do cliente. Deve-se ter cuidado ao proteger o acesso aos dados em ambos os locais para evitar o acesso indevido aos dados.

Considere o seguinte cenário em que dados meteorológicos seguros são exibidos por um componente. Demonstrações de algumas das seguintes abordagens podem ser avaliadas e testadas usando os BlazorWebAppEntra/BlazorWebAppEntraBffexemplos (.NET 9 ou posterior) ou osBlazorWebAppOidc/BlazorWebAppOidcBffexemplos (.NET 8 ou posterior) no Blazor repositório GitHub de exemplos (dotnet/blazor-samples) (como baixar).

O projeto cliente mantém uma classe WeatherForecast para armazenar dados meteorológicos:

public sealed class WeatherForecast(DateOnly date, int temperatureC, string summary)
{
    public DateOnly Date { get; set; } = date;
    public int TemperatureC { get; set; } = temperatureC;
    public string? Summary { get; set; } = summary;
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

A interface IWeatherForecaster do projeto cliente define um método GetWeatherForecastAsync para obter dados meteorológicos:

public interface IWeatherForecaster
{
    Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync();
}

O serviço de ClientWeatherForecaster do projeto cliente implementa IWeatherForecaster. O método GetWeatherForecastAsync chama uma API web no projeto do servidor no endpoint /weather-forecast para dados meteorológicos:

internal sealed class ClientWeatherForecaster(HttpClient httpClient) 
    : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync() =>
        await httpClient.GetFromJsonAsync<WeatherForecast[]>("/weather-forecast") ??
            throw new IOException("No weather forecast!");
}

O projeto cliente mantém um componente Weather que:

• Impõe a autorização com um [Authorize] atributo.
• Usa o serviço de Estado do Componente Persistente (PersistentComponentState) para persistir os dados de previsão do tempo ao fazer a transição de SSR estático para interativo no servidor. Para obter mais informações, consulte Persistência de estado pré-renderizado do núcleo ASP.NETBlazor.

@page "/weather"
@using Microsoft.AspNetCore.Authorization
@using BlazorWebAppEntra.Client.Weather
@attribute [Authorize]
@inject IWeatherForecaster WeatherForecaster

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (Forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in Forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    [PersistentState]
    public IEnumerable<WeatherForecast>? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        Forecasts ??= await WeatherForecaster.GetWeatherForecastAsync();
    }
}

@page "/weather"
@using Microsoft.AspNetCore.Authorization
@using BlazorWebAppEntra.Client.Weather
@attribute [Authorize]
@implements IDisposable
@inject PersistentComponentState ApplicationState
@inject IWeatherForecaster WeatherForecaster

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private IEnumerable<WeatherForecast>? forecasts;
    private PersistingComponentStateSubscription persistingSubscription;

    protected override async Task OnInitializedAsync()
    {
        if (!ApplicationState.TryTakeFromJson<IEnumerable<WeatherForecast>>(
            nameof(forecasts), out var restoredData))
        {
            forecasts = await WeatherForecaster.GetWeatherForecastAsync();
        }
        else
        {
            forecasts = restoredData!;
        }

        // Call at the end to avoid a potential race condition at app shutdown
        persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);
    }

    private Task PersistData()
    {
        ApplicationState.PersistAsJson(nameof(forecasts), forecasts);

        return Task.CompletedTask;
    }

    void IDisposable.Dispose() => persistingSubscription.Dispose();
}

O projeto de servidor implementa IWeatherForecaster como ServerWeatherForecaster, o que gera e retorna dados meteorológicos através do seu método GetWeatherForecastAsync.

internal sealed class ServerWeatherForecaster() : IWeatherForecaster
{
    public readonly string[] summaries =
    [
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", 
        "Sweltering", "Scorching"
    ];

    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        // Simulate asynchronous loading to demonstrate streaming rendering
        await Task.Delay(500);

        return Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ))
        .ToArray();
    }
}

Se o aplicativo precisar chamar uma API da Web externa para obter os dados meteorológicos, você poderá injetar um cliente HTTP (HttpClient) para solicitar os dados:

internal sealed class ServerWeatherForecaster(HttpClient httpClient, 
    IHttpContextAccessor httpContextAccessor) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        var httpContext = httpContextAccessor.HttpContext ??
            throw new InvalidOperationException("No HttpContext!");
        var accessToken = await httpContext.GetTokenAsync("access_token") ??
            throw new InvalidOperationException("No access_token was saved");
        using var request = 
            new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
        request.Headers.Authorization = new("Bearer", accessToken);
        using var response = await httpClient.SendAsync(request);
        response.EnsureSuccessStatusCode();

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

Em outra abordagem, pode-se injetar uma fábrica de clientes HTTP (IHttpClientFactory) no ServerWeatherForecaster e chamar uma API da Web externa usando um cliente HTTP nomeado com um manipulador de token. Para mais informações, consulte Chamar uma API da Web a partir de uma aplicação ASP.NET Core Blazor.

Se o aplicativo usa a plataforma de identidade da Microsoft com pacotes da Web da Microsoft Identity para oMicrosoft Entra ID (consulte Chamar uma API da Web de um aplicativo ASP.NET CoreBlazor), o seguinte ServerWeatherForecaster demonstra como fazer uma chamada de API da Web externa. O token de acesso é automaticamente anexado à solicitação.

internal sealed class ServerWeatherForecaster(IDownstreamApi downstreamApi) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        using var response = await downstreamApi.CallApiForUserAsync("DownstreamApi",
            options =>
            {
                options.RelativePath = "/weather-forecast";
            });

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

Independentemente da abordagem adotada pelo ServerWeatherForecaster para obter os dados, o projeto de servidor mantém um ponto de extremidade de API da Web seguro para chamadas de dados meteorológicos do cliente. Este endpoint resulta em uma ServerWeatherForecaster.GetWeatherForecastAsync invocação no servidor.

app.MapGet("/weather-forecast", (
    [FromServices] IWeatherForecaster WeatherForecaster) =>
{
    return WeatherForecaster.GetWeatherForecastAsync();
}).RequireAuthorization();

Usando a abordagem anterior, existem dois sistemas para fornecer dados meteorológicos seguros ao usuário:

• Quando o Weather componente é renderizado no servidor, o ServerWeatherForecaster método do GetWeatherForecastAsync serviço é usado diretamente para obter os dados meteorológicos. A segurança dos dados é garantida pelo atributo do componente . Em resumo, a segurança dos dados meteorológicos é imposta pelo componente.
• Quando o componente Weather é renderizado nodo cliente, o serviço ClientWeatherForecaster é usado para fazer uma chamada à API da Web para o ponto de extremidade seguro /weather-forecast que aplica o método de extensão RequireAuthorization. Se o utilizador tiver autorização para aceder aos dados meteorológicos, o ponto de extremidade usa o serviço ServerWeatherForecaster para ligar para GetWeatherForecastAsync. Os dados são devolvidos ao cliente. O servidor garante a segurança dos dados meteorológicos através do uso do endpoint da sua API web.

A abordagem anterior funciona bem quando os requisitos de segurança da API da Web correspondem aos requisitos de segurança do componente. Por exemplo, a mesma política de autorização pode ser aplicada ao ponto de extremidade da API da Web e ao componente.

Cenários complexos exigem planejamento e implementação adicionais. Por exemplo, uma API Web de servidor que tenha vários chamadores com permissões de acesso diferentes requer uma política de autorização mais sofisticada, uma ou mais políticas adicionais ou pontos de extremidade adicionais com requisitos de acesso diferentes.

Ao integrar segurança nos aplicativos que adotam renderização automática interativa, lembre-se de que a segurança implementada para os pontos de extremidade da API Web do servidor não protege a implementação do serviço do servidor usada quando um componente é renderizado no servidor e acessa dados através do serviço. Pese cuidadosamente a diferença entre acessar dados no servidor durante o SSR versus acessar os dados em uma solicitação de API da Web do cliente durante o CSR. Aplique estrategicamente a segurança para evitar o acesso indevido aos dados.

Exemplos no repositório do GitHub Blazor (dotnet/blazor-samples) (como fazer download) que demonstram a abordagem descrita nesta seção:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

AuthenticationStateProvider é o serviço subjacente usado pelo componente AuthorizeView e serviços de autenticação em cascata para obter o estado de autenticação para um usuário.

AuthenticationStateProvider é o serviço subjacente usado pelo componente AuthorizeView e pelo componente CascadingAuthenticationState para obter o estado de autenticação de um usuário.

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

No exemplo anterior:

• ClaimsPrincipal.Claims retorna as declarações do usuário (claims) para exibição na interface do usuário.
• A linha que obtém o sobrenome do usuário (surname) chama ClaimsPrincipal.FindAll com um predicado para filtrar as declarações do usuário.

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

Configure o parâmetro em cascata Task<AuthenticationState> usando os serviços de autenticação em cascata e de estado AuthorizeRouteView.

Quando você cria um aplicativo Blazor a partir de um dos modelos de projeto Blazor com a autenticação habilitada, o aplicativo inclui o AuthorizeRouteView e a chamada para AddCascadingAuthenticationState mostrados no exemplo a seguir. Uma aplicação Blazor no lado cliente também inclui os registos de serviço necessários. Informações adicionais são apresentadas na seção Personalizar o conteúdo não autorizado com o componente Router.

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

No arquivo Program, registre os serviços de estado de autenticação em cascata:

builder.Services.AddCascadingAuthenticationState();

Configure o parâmetro em cascata Task<AuthenticationState> usando os componentes AuthorizeRouteView e CascadingAuthenticationState.

Quando você cria um aplicativo Blazor a partir de um dos Blazor modelos de projeto com a autenticação habilitada, o aplicativo inclui os componentes AuthorizeRouteView e CascadingAuthenticationState mostrados no exemplo a seguir. Uma aplicação Blazor no lado cliente também inclui os registos de serviço necessários. Informações adicionais são apresentadas na seção Personalizar o conteúdo não autorizado com o componente Router.

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

Num aplicativo cliente Blazor, adicione serviços de autorização ao ficheiro Program:

builder.Services.AddAuthorizationCore();

Num app Blazor do lado do cliente, adicione opções assim como serviços de autorização ao ficheiro Program.

builder.Services.AddOptions();
builder.Services.AddAuthorizationCore();

Razor componentes do Blazor Web Appnunca exibem conteúdo <NotAuthorized> quando a autorização falha durante a renderização estática no servidor (SSR estático). O pipeline do ASP.NET Core do lado do servidor processa a autorização no servidor. Use técnicas do lado do servidor, como configurar LoginPath para lidar com pedidos não autorizados. Para obter mais informações, consulte modos de renderização do ASP.NET Core Blazor.

Autorização de recursos

Para autorizar usuários para recursos, passe os dados de rota da solicitação para o parâmetro Resource de AuthorizeRouteView.

No conteúdo do Router.Found para uma rota solicitada:

<AuthorizeRouteView Resource="routeData" RouteData="routeData" 
    DefaultLayout="typeof(MainLayout)" />

Para obter mais informações sobre como os dados de estado de autorização são passados e usados na lógica de procedimento, consulte a seção Expor o estado de autenticação como um parâmetro em cascata.

Quando o AuthorizeRouteView recebe os dados de rota para o recurso, as políticas de autorização têm acesso a RouteData.PageType e RouteData.RouteValues que permitem que a lógica personalizada tome decisões de autorização.

No exemplo a seguir, uma política de EditUser é criada em AuthorizationOptions para a configuração do serviço de autorização do aplicativo (AddAuthorizationCore) com a seguinte lógica:

• Determine se existe um valor de rota com uma chave de id. Se a chave existir, o valor da rota será armazenado em value.
• Em uma variável chamada id, armazenevalue como uma cadeia de caracteres ou defina um valor de cadeia de caracteres vazio (string.Empty).
• Se id não for uma cadeia de caracteres vazia, afirme que a política está satisfeita (retornar true) se o valor da cadeia começar com EMP. Caso contrário, afirme que a política falha (retornar false).

No ficheiro Program:

• Adicione namespaces para Microsoft.AspNetCore.Components e System.Linq:

  using Microsoft.AspNetCore.Components;
  using System.Linq;
  

• Adicione a política:

  options.AddPolicy("EditUser", policy =>
      policy.RequireAssertion(context =>
      {
          if (context.Resource is RouteData rd)
          {
              var routeValue = rd.RouteValues.TryGetValue("id", out var value);
              var id = Convert.ToString(value, 
                  System.Globalization.CultureInfo.InvariantCulture) ?? string.Empty;
  
              if (!string.IsNullOrEmpty(id))
              {
                  return id.StartsWith("EMP", StringComparison.InvariantCulture);
              }
          }
  
          return false;
      })
  );
  

O exemplo anterior é uma política de autorização excessivamente simplificada, usada apenas para demonstrar o conceito com um exemplo de trabalho. Para obter mais informações sobre como criar e configurar políticas de autorização, consulte Autorização baseada em políticas no ASP.NET Core.

No componente EditUser seguinte, o recurso em /users/{id}/edit tem um parâmetro de rota para o identificador do utilizador ({id}). O componente utiliza a anterior política de autorização de EditUser para ver se o valor de rota para id começa com EMP. Se id começar com EMP, a política será bem-sucedida e o acesso ao componente será autorizado. Se id começar com um valor diferente de EMP ou se id for uma cadeia de caracteres vazia, a política falhará e o componente não será carregado.

EditUser.razor:

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

<Router ...>
    <Found ...>
        <AuthorizeRouteView ...>
            <NotAuthorized>
                ...
            </NotAuthorized>
            <Authorizing>
                ...
            </Authorizing>
        </AuthorizeRouteView>
    </Found>
</Router>

O conteúdo de Authorized e NotAuthorized pode incluir itens arbitrários, como outros componentes interativos.

builder.Services.AddCascadingAuthenticationState();

<CascadingAuthenticationState>
    <Router ...>
        <Found ...>
            <AuthorizeRouteView ...>
                <NotAuthorized>
                    ...
                </NotAuthorized>
                <Authorizing>
                    ...
                </Authorizing>
            </AuthorizeRouteView>
        </Found>
    </Router>
</CascadingAuthenticationState>

O conteúdo de NotFound, Authorizede NotAuthorized pode incluir itens arbitrários, como outros componentes interativos.

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

• Recursos do servidor e do Blazor Web App
  • Guia de início rápido: adicionar início de sessão com a Microsoft a uma aplicação Web ASP.NET Core
  • Guia de início rápido: proteja uma API Web ASP.NET Core com a plataforma de identidade da Microsoft
  • Configure o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga: Inclui orientações sobre:
    • Usar o Middleware de Cabeçalhos Reencaminhados para manter as informações do esquema HTTPS em servidores proxy e redes internas.
    • Cenários e casos de uso adicionais, incluindo configuração manual do esquema, alterações de caminho de pedido para o roteamento correto das solicitações e o encaminhamento do esquema de pedido para proxies reversos em Linux e não-IIS.
• Documentação da plataforma de identidade da Microsoft
  • Overview
  • Protocolos OAuth 2.0 e OpenID Connect na plataforma de identidade da Microsoft
  • Plataforma de identidade da Microsoft e fluxo de código de autorização OAuth 2.0
  • Tokens de ID da plataforma de identidade da Microsoft
  • Tokens de acesso à plataforma de identidade da Microsoft
• ASP.NET Principais tópicos de segurança
• Configurar a autenticação do Windows no ASP.NET Core
• IHttpContextAccessor/HttpContext em aplicativos ASP.NET Core Blazor
• Crie uma versão personalizada da biblioteca JavaScript Authentication.MSAL
• Awesome Blazor: Autenticação exemplos de links da comunidade
• Autenticação e autorização ASP.NET Core Blazor Hybrid

• Recursos de Blazor do lado do servidor
  • Guia de início rápido: adicionar início de sessão com a Microsoft a uma aplicação Web ASP.NET Core
  • Guia de início rápido: proteja uma API Web ASP.NET Core com a plataforma de identidade da Microsoft
  • Configure o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga: Inclui orientações sobre:
    • Usar o Middleware de Cabeçalhos Reencaminhados para manter as informações do esquema HTTPS em servidores proxy e redes internas.
    • Cenários e casos de uso adicionais, incluindo configuração manual do esquema, alterações de caminho de pedido para o roteamento correto das solicitações e o encaminhamento do esquema de pedido para proxies reversos em Linux e não-IIS.
• Documentação da plataforma de identidade da Microsoft
  • Overview
  • Protocolos OAuth 2.0 e OpenID Connect na plataforma de identidade da Microsoft
  • Plataforma de identidade da Microsoft e fluxo de código de autorização OAuth 2.0
  • Tokens de ID da plataforma de identidade da Microsoft
  • Tokens de acesso à plataforma de identidade da Microsoft
• ASP.NET Principais tópicos de segurança
• IHttpContextAccessor/HttpContext em aplicativos ASP.NET Core Blazor
• Configurar a autenticação do Windows no ASP.NET Core
• Crie uma versão personalizada da biblioteca JavaScript Authentication.MSAL
• Awesome Blazor: Autenticação exemplos de links da comunidade