Uwierzytelnianie i autoryzacja na platformie ASP.NET Core Blazor

W tym artykule opisano obsługę konfiguracji i zarządzania zabezpieczeniami w aplikacjach Blazor na platformie ASP.NET Core.

Blazor używa istniejących mechanizmów uwierzytelniania ASP.NET Core w celu ustanowienia tożsamości użytkownika. Dokładny mechanizm zależy od sposobu, w jaki Blazor aplikacja jest hostowana, po stronie serwera lub po stronie klienta.

Scenariusze zabezpieczeń różnią się między kodem autoryzacji działającym po stronie serwera i po stronie klienta w Blazor aplikacjach. W przypadku kodu autoryzacji uruchamianego na serwerze kontrole autoryzacji są w stanie wymusić reguły dostępu dla obszarów aplikacji i składników. Ponieważ wykonywanie kodu po stronie klienta może być manipulowane, kod autoryzacji wykonywany na kliencie nie może być zaufany do absolutnego egzekwowania zasad dostępu ani kontrolowania wyświetlania treści po stronie klienta.

Jeśli wymuszanie reguły autoryzacji musi być gwarantowane, nie implementuj kontroli autoryzacji w kodzie po stronie klienta. Utwórz element Blazor Web App , który opiera się tylko na renderowaniu po stronie serwera (SSR) na potrzeby kontroli autoryzacji i wymuszania reguł.

Konwencje autoryzacji Razor Pages nie mają zastosowania do routowalnych komponentów Razor. Jeśli nieroutowalny składnik Razor jest osadzony na stronie aplikacji Razor Pages, konwencje autoryzacji strony pośrednio wpływają na składnik Razor oraz resztę zawartości strony.

Uwaga

Przykłady kodu w tym artykule przyjmują typy odwołań dopuszczających wartość null (NRTs) i statyczną analizę stanu null kompilatora platformy .NET, które są obsługiwane w programie ASP.NET Core na platformie .NET 6 lub nowszym. Podczas pracy z ASP.NET Core w wersji 5.0 lub starszej usuń oznaczenie typu null (?) z przykładów w tym artykule.

Bezpieczne utrzymywanie poufnych danych i poświadczeń

Nie przechowuj tajnych danych aplikacji, ciągów znaków połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu .NET/C# ani kluczy prywatnych/tokenów w kodzie po stronie klienta, który jest zawsze niepewny. Kod po stronie Blazor klienta powinien uzyskiwać dostęp do bezpiecznych usług i baz danych za pośrednictwem bezpiecznego internetowego interfejsu API, który kontrolujesz.

W środowiskach testowych/przejściowych i produkcyjnych kod po stronie Blazor serwera i internetowe interfejsy API powinny używać bezpiecznych przepływów uwierzytelniania, które unikają utrzymywania poświadczeń w kodzie projektu lub plikach konfiguracji. Poza lokalnymi testami programistycznymi zalecamy unikanie używania zmiennych środowiskowych do przechowywania poufnych danych, ponieważ zmienne środowiskowe nie są najbezpieczniejszym podejściem. W przypadku lokalnego testowania programistycznego narzędzie Secret Manager jest zalecane do zabezpieczania poufnych danych. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Bezpieczne przepływy uwierzytelniania (dokumentacja ASP.NET Core)
• Tożsamości zarządzane dla usług platformy Microsoft Azure (ten artykuł)

W przypadku programowania i testowania lokalnego po stronie klienta i po stronie serwera użyj narzędzia Secret Manager, aby zabezpieczyć poufne poświadczenia.

Tożsamości zarządzane dla usług platformy Microsoft Azure

W przypadku usług platformy Microsoft Azure zalecamy używanie tożsamości zarządzanych. Identyfikatory zarządzane bezpiecznie uwierzytelniają się do usług Azure, bez przechowywania poświadczeń w kodzie aplikacji. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Co to są tożsamości zarządzane dla zasobów platformy Azure? (Dokumentacja firmy Microsoft Entra)
• Dokumentacja usług platformy Azure
  • Tożsamości zarządzane w usłudze Microsoft Entra for Azure SQL
  • Jak używać tożsamości zarządzanych dla usług App Service i Azure Functions

Obsługa funkcji antyfałszerzowych

Szablon Blazor :

• Automatycznie dodaje usługi antyfałszerzowe, gdy AddRazorComponents jest wywoływane w pliku Program.
• Dodaje oprogramowanie pośredniczące chroniące przed fałszerstwem, wywołując UseAntiforgery w potoku przetwarzania żądań w pliku Program i wymagając ochrony antyfałszerstwowej punktu końcowego, aby ograniczyć zagrożenia fałszerstwa żądań między witrynami (CSRF/XSRF). UseAntiforgery jest wywoływana po UseHttpsRedirection. Wywołanie UseAntiforgery musi zostać umieszczone po wywołaniach do UseAuthentication i UseAuthorization, jeśli istnieją.

Składnik AntiforgeryToken renderuje token antyforgery jako ukryte pole, a składnik ten jest automatycznie dodawany do instancji formularza (EditForm). Aby uzyskać więcej informacji, zobacz przegląd formularzy ASP.NET Core.

AntiforgeryStateProvider Usługa zapewnia dostęp do tokenu antyforgery skojarzonego z bieżącą sesją. Wstrzyknij usługę i wywołaj jej GetAntiforgeryToken() metodę w celu uzyskania bieżącego AntiforgeryRequestToken elementu. Aby uzyskać więcej informacji, zobacz Wywoływanie interfejsu API z aplikacji ASP.NET Core.

Blazor przechowuje tokeny żądań w stanie składnika, co gwarantuje, że tokeny antyforgeryjne są dostępne dla składników interaktywnych, nawet jeśli nie mają dostępu do żądania.

Uwaga

Środki zapobiegawcze przed fałszowaniem są wymagane tylko podczas przesyłania danych formularza do serwera zakodowanego jako application/x-www-form-urlencoded, multipart/form-data lub text/plain, ponieważ są to jedyne prawidłowe typy kodowania formularza.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Zapobieganie atakom fałszowania żądań między witrynami (XSRF/CSRF) w ASP.NET Core: ten artykuł jest podstawowym artykułem ASP.NET Core na ten temat, który dotyczy po stronie Blazor Serverserwera, projektu Blazor Web Appserwera s i Blazor integracji z MVC/Razor Pages.
• ASP.NET Core Przegląd formularzy: Sekcja wsparcia ochrony przed fałszerstwem w artykule dotyczy Blazor wsparcia ochrony przed fałszerstwem formularzy.

Uwierzytelnianie po stronie Blazor serwera

Aplikacje po stronie Blazor serwera są konfigurowane pod kątem zabezpieczeń w taki sam sposób jak aplikacje ASP.NET Core. Aby uzyskać więcej informacji, zobacz artykuły w tematach dotyczących zabezpieczeń platformy ASP.NET Core.

Kontekst uwierzytelniania jest ustanawiany tylko po uruchomieniu aplikacji, czyli wtedy, gdy aplikacja po raz pierwszy łączy się z WebSocket poprzez SignalR połączenie z klientem. Uwierzytelnianie może być oparte na tokenie elementu nośnego cookie lub innego elementu nośnego, ale uwierzytelnianie jest zarządzane za pośrednictwem SignalR centrum i w całości w obrębie obwodu. Kontekst uwierzytelniania jest utrzymywany przez cały okres istnienia toru. Aplikacje okresowo zmieniają stan uwierzytelniania użytkownika co 30 minut.

Jeśli aplikacja musi przechwytywać użytkowników dla usług niestandardowych lub reagować na aktualizacje użytkownika, zobacz ASP.NET Core po stronie serwera i Blazor Web App dodatkowe scenariusze zabezpieczeń.

Blazor różni się od tradycyjnych aplikacji internetowych, renderowanych przez serwer, które tworzą nowe żądania HTTP z plikami cookie przy każdej nawigacji po stronie. Uwierzytelnianie jest sprawdzane podczas zdarzeń związanych z nawigacją. Pliki cookie nie są jednak zaangażowane. Pliki cookie są wysyłane tylko podczas wysyłania żądania HTTP do serwera, co nie występuje podczas nawigacji użytkownika w aplikacji Blazor. Podczas nawigacji stan uwierzytelniania użytkownika jest sprawdzany w ramach obwodu Blazor, który można aktualizować w dowolnym momencie na serwerze przy użyciu RevalidatingAuthenticationStateProvider abstrakcji.

Ważne

Implementowanie niestandardowego NavigationManager do weryfikacji uwierzytelnienia podczas nawigacji nie jest zalecane. Jeśli aplikacja musi wykonywać niestandardową logikę stanu uwierzytelniania podczas nawigacji, użyj niestandardowego AuthenticationStateProvider.

Uwaga

Przykłady kodu w tym artykule przyjmują typy odwołań dopuszczających wartość null (NRTs) i statyczną analizę stanu null kompilatora platformy .NET, które są obsługiwane w programie ASP.NET Core na platformie .NET 6 lub nowszym. W przypadku, gdy aplikacja jest przeznaczona dla ASP.NET Core 5.0 lub starszej, usuń oznaczenie typu null (?) z przykładów w tym artykule.

Wbudowana lub niestandardowa usługa AuthenticationStateProvider uzyskuje dane stanu uwierzytelniania z komponentu HttpContext.User ASP.NET Core. W ten sposób stan uwierzytelnienia integruje się z istniejącymi mechanizmami uwierzytelnianie platformy ASP.NET Core.

Aby uzyskać więcej informacji na temat uwierzytelniania po stronie serwera, zobacz ASP.NET Podstawowe Blazor uwierzytelnianie i autoryzacja.

Stan udostępniony

Aplikacje po stronie Blazor serwera działają w pamięci serwera, a wiele sesji aplikacji jest hostowanych w ramach tego samego procesu. Dla każdej sesji aplikacji Blazor rozpoczynany jest cykl z własnym zakresem kontenera wstrzykiwania zależności, a usługi o tym zakresie są unikalne dla sesji Blazor.

Ostrzeżenie

Nie zalecamy, aby aplikacje działające na tym samym serwerze udostępniały stan przy użyciu usług singleton, chyba że zostanie podjęta skrajna ostrożność, ponieważ może to powodować zagrożenia dla bezpieczeństwa, takie jak wyciek stanu użytkownika w różnych połączeniach.

Możesz używać usług singletonowych z pamięcią stanu w aplikacjach Blazor, jeśli są one specjalnie zaprojektowane do tego celu. Na przykład użycie pojedynczej pamięci podręcznej (singleton) jest dopuszczalne, ponieważ pamięć podręczna wymaga klucza, aby uzyskać dostęp do danego wpisu. Zakładając, że użytkownicy nie mają kontroli nad kluczami pamięci podręcznej używanymi z pamięcią podręczną, stan przechowywany w pamięci podręcznej nie przecieka między obwodami.

Aby uzyskać ogólne wskazówki dotyczące zarządzania stanem, zobacz ASP.NET Core Blazor zarządzanie stanem.

Zabezpieczenia po stronie serwera poufnych danych i poświadczeń

W środowiskach testowych/przejściowych i produkcyjnych kod po stronie Blazor serwera i internetowe interfejsy API powinny używać bezpiecznych przepływów uwierzytelniania, które unikają utrzymywania poświadczeń w kodzie projektu lub plikach konfiguracji. Poza lokalnymi testami programistycznymi zalecamy unikanie używania zmiennych środowiskowych do przechowywania poufnych danych, ponieważ zmienne środowiskowe nie są najbezpieczniejszym podejściem. W przypadku lokalnego testowania programistycznego narzędzie Secret Manager jest zalecane do zabezpieczania poufnych danych. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Bezpieczne przepływy uwierzytelniania (dokumentacja ASP.NET Core)
• Tożsamości zarządzane dla usług platformy Microsoft Azure (Blazor dokumentacja)

W przypadku programowania i testowania lokalnego po stronie klienta i po stronie serwera użyj narzędzia Secret Manager, aby zabezpieczyć poufne poświadczenia.

Szablon projektu

Utwórz nową aplikację po stronie Blazor serwera, korzystając ze wskazówek zawartych w Tooling for ASP.NET CoreBlazor.

Visual Studio

Po wybraniu szablonu aplikacji po stronie serwera i skonfigurowaniu projektu wybierz uwierzytelnianie aplikacji w obszarze Typ uwierzytelniania:

• Brak (wartość domyślna): brak uwierzytelniania.
• Indywidualne konta: konta użytkowników są przechowywane w aplikacji przy użyciu ASP.NET Core Identity.

Visual Studio Code

Podczas wydawania polecenia .NET CLI do utworzenia i skonfigurowania aplikacji po stronie Blazor serwera, wskaż mechanizm uwierzytelniania za pomocą opcji -au|--auth.

-au {AUTHENTICATION}

Uwaga

Aby uzyskać pełne polecenie, zobacz Tooling for ASP.NET Core (Narzędzia dla platformy ASP.NET Core Blazor).

Dopuszczalne wartości uwierzytelniania dla symbolu zastępczego {AUTHENTICATION} są wyświetlane w poniższej tabeli.

Mechanizm uwierzytelniania	opis
None (domyślne)	Bez uwierzytelniania
Individual	Użytkownicy przechowywani w aplikacji przy użyciu systemu ASP.NET Core Identity

Aby uzyskać więcej informacji, zobacz polecenie dotnet new w Przewodniku platformy .NET Core.

.NET CLI

Podczas wydawania polecenia .NET CLI w celu utworzenia i skonfigurowania aplikacji po stronie Blazor serwera, wskaż mechanizm uwierzytelniania za pomocą opcji -au|--auth.

-au {AUTHENTICATION}

Uwaga

Aby uzyskać pełne polecenie, zobacz Tooling for ASP.NET Core (Narzędzia dla platformy ASP.NET Core Blazor).

Dopuszczalne wartości uwierzytelniania dla symbolu zastępczego {AUTHENTICATION} są wyświetlane w poniższej tabeli.

Mechanizm uwierzytelniania	Opis
None (domyślne)	Bez uwierzytelniania
Individual	Użytkownicy przechowywani w aplikacji przy użyciu systemu ASP.NET Core Identity

Więcej informacji:

• Zobacz polecenie dotnet new w Przewodniku platformy .NET Core.

• Wykonaj polecenie pomocy dla szablonu w wierszu poleceń.

  dotnet new {PROJECT TEMPLATE} --help
  

  W poprzednim poleceniu {PROJECT TEMPLATE} symbol zastępczy jest szablonem projektu.

Blazor Identity Interfejs użytkownika (indywidualne konta)

Program wspiera generowanie pełnego interfejsu użytkownika opartego na i , kiedy wybierasz opcję uwierzytelniania dla kont indywidualnych .

Szablon Blazor Web App generuje Identity kod dla bazy danych SQL Server. Wersja wiersza polecenia używa biblioteki SQLite i zawiera bazę danych SQLite dla programu Identity.

Szablon:

• Obsługuje interaktywne renderowanie po stronie serwera (interakcyjne SSR) i scenariusze renderowania po stronie klienta (CSR) z uwierzytelnionymi użytkownikami.
• Dodaje IdentityRazor składniki i powiązaną logikę dla rutynowych zadań uwierzytelniania, takich jak logowanie i wylogowywanie użytkowników. Składniki Identity obsługują również zaawansowane Identity funkcje, takie jak potwierdzenie konta i odzyskiwanie hasła oraz uwierzytelnianie wieloskładnikowe przy użyciu aplikacji innej firmy. Należy pamiętać, że Identity same składniki nie obsługują interakcyjności.
• Dodaje pakiety i zależności związane z Identity.
• Odwołuje się do Identity pakietów w pliku _Imports.razor.
• Tworzy niestandardową klasę użytkownika Identity (ApplicationUser).
• Tworzy i rejestruje EF Core kontekst bazy danych (ApplicationDbContext).
• Konfiguruje routing dla wbudowanych Identity punktów końcowych.
• Obejmuje Identity walidację i logikę biznesową.

Aby sprawdzić Blazor składniki platformyIdentity, uzyskaj dostęp do nich w Pages folderachSharedi Account w szablonie Blazor Web App projektu (źródle odwołania).

Po wybraniu trybów renderowania Interactive WebAssembly lub Interactive Auto serwer obsługuje wszystkie żądania uwierzytelniania i autoryzacji, a Identity składniki są renderowane statycznie na serwerze w głównym projekcie Blazor Web App.

Platforma udostępnia niestandardowe AuthenticationStateProvider zarówno w projektach serwera, jak i klienta (.Client) w celu przepływu stanu uwierzytelniania użytkownika do przeglądarki. Projekt serwera wywołuje metodę AddAuthenticationStateSerialization, podczas gdy projekt klienta wywołuje metodę AddAuthenticationStateDeserialization. Uwierzytelnianie na serwerze zamiast na kliencie pozwala aplikacji na dostęp do stanu uwierzytelnienia podczas wstępnego renderowania i zanim zostanie zainicjowane środowisko uruchomieniowe WebAssembly dla platformy .NET. Implementacje niestandardowe AuthenticationStateProvider używają usługi stanu trwałego składnika (PersistentComponentState) do serializacji stanu uwierzytelniania w komentarzach HTML, a następnie odczytują go z powrotem z zestawu WebAssembly w celu utworzenia nowego AuthenticationState wystąpienia. Aby uzyskać więcej informacji, zobacz sekcję Zarządzanie stanem uwierzytelniania w Blazor Web Appsekcji s .

Tylko w przypadku rozwiązań Interactive Server (źródło referencyjne) po stronie serwera IdentityRevalidatingAuthenticationStateProviderAuthenticationStateProvider, które ponownie weryfikuje sygnaturę zabezpieczeń dla połączonego użytkownika co 30 minut trwania połączenia interaktywnego.

Blazor Identity jest zależne DbContext od instancji, które nie są tworzone przez fabrykę, co jest celowe, ponieważ DbContext jest wystarczający, aby składniki szablonu Identity projektu były renderowane statycznie bez obsługi interaktywności.

Aby zapoznać się z opisem sposobu stosowania globalnych trybów renderowania interaktywnego do składników innych niż Identity, a jednocześnie wymuszania statycznego SSR dla składników Identity, zobacz ASP.NET Core tryby renderowaniaBlazor.

Aby uzyskać więcej informacji na temat utrwalania stanu prerenderowanego, zobacz Składniki prerenderowane w ASP.NET Core.

Uwaga

Linki dokumentacji do źródła referencyjnego platformy .NET zwykle prowadzą do domyślnej gałęzi repozytorium, która odzwierciedla bieżący rozwój dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Zarządzanie stanem uwierzytelniania w Blazor Web App

Ta sekcja ma zastosowanie do Blazor Web Apptych, które przyjmują:

• Indywidualne konta
• Renderowanie po stronie klienta (CSR, interakcyjność oparta na zestawie WebAssembly).

Dostawca stanu uwierzytelniania po stronie klienta jest używany tylko w ramach Blazor programu i nie jest zintegrowany z systemem uwierzytelniania ASP.NET Core. Podczas prerenderingu Blazor uwzględnia metadane zdefiniowane na stronie i używa systemu uwierzytelniania ASP.NET Core w celu określenia, czy użytkownik jest uwierzytelniony. Gdy użytkownik przechodzi z jednej strony do innej, jest używany dostawca uwierzytelniania po stronie klienta. Gdy użytkownik odświeża stronę (pełne przeładowanie strony), kliencki dostawca stanu uwierzytelniania nie bierze udziału w decyzji uwierzytelniania na serwerze. Ponieważ stan użytkownika nie jest utrwalany przez serwer, każdy stan uwierzytelniania utrzymywany po stronie klienta zostanie utracony.

Aby rozwiązać ten problem, najlepszym rozwiązaniem jest przeprowadzenie uwierzytelniania w systemie uwierzytelniania ASP.NET Core. Dostawca stanu uwierzytelniania po stronie klienta zajmuje się tylko odzwierciedleniem stanu uwierzytelniania użytkownika. Przykłady tego, jak to zrobić za pomocą dostawców stanu uwierzytelniania, są przedstawiane w szablonie projektu Blazor Web App i opisane poniżej.

W pliku projektu Program serwera wywołaj metodę AddAuthenticationStateSerialization, która serializuje AuthenticationState zwrócone po stronie serwera przez AuthenticationStateProvider, przy użyciu usługi stanu trwałego komponentu (PersistentComponentState):

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

Interfejs API serializuje tylko żądania nazw i ról po stronie serwera, aby były dostępne w przeglądarce. Aby uwzględnić wszystkie roszczenia, ustaw SerializeAllClaims na true w wywołaniu po stronie serwera do AddAuthenticationStateSerialization:

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

W pliku projektu klienta (.Client) wywołaj AddAuthenticationStateDeserialization, co dodaje AuthenticationStateProvider, w której AuthenticationState jest deserializowane z serwera przy użyciu usługi Trwały stan składnika (PersistentComponentState). W projekcie serwera powinno istnieć odpowiednie wywołanie AddAuthenticationStateSerialization.

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

Dodatkowe oświadczenia i tokeny od dostawców zewnętrznych

Aby przechowywać dodatkowe oświadczenia od dostawców zewnętrznych, zobacz Utrwalanie dodatkowych oświadczeń i tokenów od dostawców zewnętrznych na platformie ASP.NET Core.

Usługa Azure App Service dla systemu Linux z serwerem Identity

Jawnie określ wystawcę podczas wdrażania na platformie Azure App Service dla systemu Linux z serwerem Identity. Aby uzyskać więcej informacji, zobacz Użycie Identity do zabezpieczenia zaplecza API internetowego dla SPA.

Wstrzyknij AuthenticationStateProvider dla usług o zakresie komponentu

Nie próbuj rozwiązywać problemów AuthenticationStateProvider w zakresie niestandardowym, ponieważ powoduje utworzenie nowego wystąpienia obiektu AuthenticationStateProvider , które nie zostało poprawnie zainicjowane.

Aby uzyskać dostęp do AuthenticationStateProvider w ramach usługi obejmującej komponent, należy wstrzyknąć AuthenticationStateProvider do komponentu i przekazać go do usługi jako parametr. Takie podejście gwarantuje, że poprawne, zainicjowane wystąpienie AuthenticationStateProvider obiektu jest używane dla każdego wystąpienia aplikacji użytkownika.

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.";
        }
    }
}

Zarejestruj usługę w określonym zakresie. W aplikacji po stronie Blazor serwera zakres usług ma okres istnienia równy czasowi trwania obwodu połączenia klienta.

W pliku Program:

builder.Services.AddScoped<ExampleService>();

W poniższym składniku InjectAuthStateProvider:

• Składnik dziedziczy element OwningComponentBase.
• Element AuthenticationStateProvider jest wstrzykiwany i przekazywany do ExampleService.ExampleMethod.
• ExampleService jest rozwiązany za pomocą OwningComponentBase.ScopedServices i GetRequiredService, które zwraca poprawne, zainicjowane wystąpienie ExampleService, które istnieje przez okres istnienia obwodu użytkownika.

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

Aby uzyskać więcej informacji, zobacz wskazówki dotyczące OwningComponentBase w ASP.NET Core Blazor wstrzykiwaniu zależności.

Wyświetlanie nieautoryzowanej zawartości podczas prerenderingu za pomocą niestandardowego AuthenticationStateProvider

Aby uniknąć wyświetlania nieautoryzowanej zawartości, na przykład zawartości w składniku , podczas prerenderowania z niestandardowym elementem , należy zastosować jedną z następujących metod:

• Zaimplementuj IHostEnvironmentAuthenticationStateProvider dla niestandardowego AuthenticationStateProvider, aby obsługiwać prerendering: dla przykładu implementacji IHostEnvironmentAuthenticationStateProvider zobacz implementację ServerAuthenticationStateProvider w ramach Blazor w ServerAuthenticationStateProvider.cs (źródło referencyjne).

  Uwaga

  Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

• Wyłącz prerendering: wskazując tryb renderowania z parametrem prerender ustawionym na false w najwyższym poziomie składnika w hierarchii składników aplikacji, który nie jest składnikiem korzeniowym.

  Uwaga

  Tworzenie interaktywnego składnika głównego, takiego jak składnik App, nie jest obsługiwane. W związku z tym prerendering nie może być wyłączony bezpośrednio przez App komponent.

  W przypadku aplikacji opartych na szablonie Blazor Web App projektu prerendering jest zazwyczaj wyłączony, gdy składnik Routes jest używany w składniku App (Components/App.razor) :

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

  Ponadto wyłącz prerendering dla HeadOutlet komponentu:

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

  Można również selektywnie zarządzać trybem renderowania zastosowanym do komponentu Routes. Na przykład, zobacz tryby renderowania ASP.NET Core.

• Uwierzytelnij użytkownika na serwerze przed uruchomieniem aplikacji: aby przyjąć to podejście, aplikacja musi odpowiadać na początkowe żądanie użytkownika stroną lub widokiem logowania opartym na Identity i uniemożliwić wysyłanie żądań do punktów końcowych Blazor do czasu ich uwierzytelnienia. Aby uzyskać więcej informacji, zobacz Tworzenie aplikacji ASP.NET Core z danymi użytkownika chronionymi przez autoryzację. Po uwierzytelnieniu nieautoryzowana zawartość w prerenderowanych Razor składnikach jest wyświetlana tylko wtedy, gdy użytkownik jest naprawdę nieautoryzowany do wyświetlania zawartości.

Zarządzanie stanem użytkownika

Pomimo słowa "state" w nazwie AuthenticationStateProvider nie jest przeznaczony do przechowywania stanu użytkownika ogólnego. AuthenticationStateProvider tylko wskazuje stan uwierzytelniania użytkownika w aplikacji, czy są zalogowani do aplikacji i kim są zalogowani.

Uwierzytelnianie używa tego samego uwierzytelniania ASP.NET Core Identity co Razor aplikacje Pages i MVC. Stan użytkownika przechowywany dla ASP.NET Core Identity przepływa do Blazor bez konieczności dodawania dodatkowego kodu do aplikacji. Postępuj zgodnie ze wskazówkami w artykułach i samouczkach dotyczących ASP.NET Core Identity, aby funkcje Identity zadziałały w Blazor częściach aplikacji.

Aby uzyskać wskazówki dotyczące ogólnego zarządzania stanem poza ASP.NET Core Identity, zobacz zarządzanie stanem w ASP.NET Core.

Dodatkowe abstrakcje zabezpieczeń

Dwie dodatkowe abstrakcje uczestniczą w zarządzaniu stanem uwierzytelniania:

• ServerAuthenticationStateProvider (źródło odniesienia): Element AuthenticationStateProvider, który jest używany przez platformę Blazor do uzyskiwania stanu uwierzytelniania z serwera.

• RevalidatingServerAuthenticationStateProvider (źródło referencyjne): klasa bazowa usług AuthenticationStateProvider używanych przez Blazor platformę do odbierania stanu uwierzytelniania ze środowiska hosta i ich ponownego aktualizowania w regularnych odstępach czasu.

  Domyślny 30-minutowy interwał ponownej walidacji można dostosować w RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs). Poniższy przykład skraca interwał do 20 minut:

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

Uwaga

Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Zarządzanie stanem uwierzytelniania przy wylogowywaniu

Po stronie Blazor serwera stan uwierzytelniania użytkownika jest utrwalany przez cały okres istnienia obwodu, w tym na kartach przeglądarki. Aby automatycznie wylogować użytkownika we wszystkich kartach przeglądarki, gdy wyloguje się na jednej z nich, musisz zaimplementować RevalidatingServerAuthenticationStateProvider (referencyjne źródło) z krótkim RevalidationInterval.

Uwaga

Linki dokumentacji do źródła referencyjnego .NET zwykle ładują domyślną gałąź repozytorium, która reprezentuje bieżący rozwój nadchodzącego wydania .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Czas trwania ważności tymczasowego adresu URL przekierowania

Ta sekcja dotyczy Blazor Web App.

Użyj opcji RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration, aby uzyskać lub ustawić czas ważności ochrony danych ASP.NET Core dla tymczasowych adresów URL przekierowania generowanych przez renderowanie po stronie serwera Blazor. Są one używane tylko w sposób przejściowy, więc okres istnienia musi być wystarczająco długi, aby klient odbierał adres URL i rozpoczynał nawigację do niego. Jednak powinno to być również wystarczająco długie, aby umożliwić rozbieżność zegara na serwerach. Wartość domyślna to pięć minut.

W poniższym przykładzie wartość jest rozszerzona do siedmiu minut:

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

Uwierzytelnianie po stronie Blazor klienta

W aplikacjach po stronie klienta można pominąć kontrole uwierzytelniania po stronie Blazor klienta, ponieważ cały kod po stronie klienta może być modyfikowany przez użytkowników. To samo dotyczy wszystkich technologii aplikacji po stronie klienta, w tym frameworków SPA JavaScript i aplikacji natywnych dla dowolnego systemu operacyjnego.

Dodaj następujące elementy:

• Odwołanie do pakietu Microsoft.AspNetCore.Components.Authorization NuGet.

  Uwaga

  Aby uzyskać instrukcje dodawania pakietów do aplikacji .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w temacie Przepływ pracy użycia pakietów (dokumentacja programu NuGet). Sprawdź prawidłowe wersje pakietów pod adresem NuGet.org.

• Przestrzeń nazw Microsoft.AspNetCore.Components.Authorization w pliku _Imports.razor aplikacji.

Aby obsłużyć uwierzytelnianie, użyj wbudowanej lub niestandardowej AuthenticationStateProvider usługi.

Aby uzyskać więcej informacji na temat uwierzytelniania po stronie klienta, zobacz Secure ASP.NET Core Blazor WebAssembly.

Zabezpieczaj dane w Blazor Web Apps za pomocą automatycznego renderowania interaktywnego

Gdy Blazor Web App przyjmuje renderowanie po stronie serwera (SSR) i renderowanie po stronie klienta (CSR) dla składników lub całej aplikacji, która określa tryb automatycznego renderowania interaktywnego, autoryzacja dostępu do składników i danych jest realizowana w dwóch punktach. Składnik ogranicza dostęp do samego siebie (i wszelkich danych, które uzyskuje) podczas renderowania na serwerze z powodu atrybutu autoryzacji w pliku definicji składnika (@attribute [Authorize]). Gdy składnik jest renderowany na kliencie, dostęp do danych jest ograniczony za pośrednictwem punktów końcowych internetowego interfejsu API serwera, które są wywoływane z klienta. Należy zachować ostrożność podczas zabezpieczania dostępu do danych w obu lokalizacjach, aby zapobiec niewłaściwemu dostępowi do danych.

Rozważmy następujący scenariusz, w którym bezpieczne dane pogodowe są wyświetlane przez składnik. Poniższy przykład można zbadać i zademonstrować w uruchomionej przykładowej aplikacji przy użyciu przykładów BlazorWebAppEntra/BlazorWebAppEntraBff (.NET 9 lub nowszej) lub przykładu BlazorWebAppOidc (.NET 8 lub nowszego) w repozytorium GitHub przykładów Blazor (dotnet/blazor-samples) (jak pobrać).

Projekt klienta utrzymuje klasę WeatherForecast do przechowywania danych pogodowych:

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

Interfejs IWeatherForecaster projektu klienta definiuje metodę GetWeatherForecastAsync uzyskiwania danych pogodowych:

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

Usługa ClientWeatherForecaster projektu klienta implementuje IWeatherForecaster. Metoda GetWeatherForecastAsync wywołuje internetowy interfejs API w projekcie serwera w punkcie końcowym /weather-forecast dla danych pogodowych:

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

Projekt klienta utrzymuje składnik Weather, który:

• Wymusza autoryzację za pomocą atrybutu [Authorize].
• Używa usługi trwałego stanu składnika (PersistentComponentState) do zapisywania danych prognozy pogody, gdy składnik przechodzi z renderowania statycznego do interakcyjnego SSR na serwerze.

@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()
    {
        persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);

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

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

        return Task.CompletedTask;
    }

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

Projekt serwera implementuje IWeatherForecaster jako ServerWeatherForecaster, który generuje i zwraca symulowane dane pogodowe za pośrednictwem metody GetWeatherForecastAsync.

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

Projekt serwera obsługuje bezpieczny punkt końcowy API dla wywołań danych o pogodzie klienta.

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

Korzystając z powyższego podejścia, istnieją dwa systemy, które udostępniają użytkownikowi bezpieczne dane pogodowe:

• Gdy składnik Weather jest renderowany na serwerze, metoda GetWeatherForecastAsync usługi ServerWeatherForecaster jest używana bezpośrednio do uzyskiwania danych pogodowych. Zabezpieczenia danych są wymuszane przez atrybut [Authorize] składnika. Podsumowując, bezpieczeństwo danych pogodowych jest zapewniane przez składnik.
• Gdy składnik Weather jest renderowany na kliencie, usługa ClientWeatherForecaster służy do wywołania internetowego przez interfejs API do bezpiecznego punktu końcowego /weather-forecast, który stosuje metodę rozszerzenia RequireAuthorization. Jeśli użytkownik ma uprawnienia dostępu do danych pogodowych, punkt końcowy używa usługi ServerWeatherForecaster do wywołania GetWeatherForecastAsync. Dane są zwracane do klienta. Podsumowując, bezpieczeństwo danych pogodowych jest wymuszane przez internetowy punkt końcowy API aplikacji serwera.

Powyższe podejście sprawdza się dobrze, gdy wymagania dotyczące zabezpieczeń internetowego interfejsu API są zgodne z wymaganiami dotyczącymi zabezpieczeń składnika. Na przykład te same zasady autoryzacji można zastosować zarówno do internetowego punktu końcowego interfejsu API, jak i składnika.

Złożone scenariusze wymagają dodatkowego planowania i implementacji. Na przykład internetowy interfejs API serwera z wieloma obiektami wywołującymi z różnymi uprawnieniami dostępu wymaga bardziej zaawansowanych zasad autoryzacji, co najmniej jednej dodatkowej zasady lub dodatkowych punktów końcowych z różnymi wymaganiami dostępu.

Podczas tworzenia zabezpieczeń w aplikacjach, które przyjmują renderowanie interakcyjne, należy pamiętać, że zabezpieczenia zaimplementowane dla punktów końcowych internetowego interfejsu API serwera nie zabezpieczają implementacji usługi serwera, która jest używana, gdy składnik jest renderowany na serwerze i uzyskuje dostęp do danych za pośrednictwem usługi. Dokładnie rozważ różnicę między uzyskiwaniem dostępu do danych na serwerze podczas renderowania po stronie serwera (SSR) a uzyskiwaniem dostępu do danych przez interfejs API klienta podczas renderowania po stronie klienta (CSR). Strategiczne stosowanie zabezpieczeń w celu uniknięcia nieprawidłowego dostępu do danych.

Przykłady w repozytorium przykładów na GitHubie Blazor (dotnet/blazor-samples) (jak pobrać), które demonstrują podejście opisane w tej sekcji:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

Usługa AuthenticationStateProvider

AuthenticationStateProvider to podstawowa usługa używana przez AuthorizeView składnik i kaskadowe usługi uwierzytelniania w celu uzyskania stanu uwierzytelniania dla użytkownika.

Zazwyczaj nie używa się usługi AuthenticationStateProvider bezpośrednio. Skorzystaj ze składnika AuthorizeView lub metod Task<AuthenticationState> opisanych w dalszej części tego artykułu. Główną wadą bezpośredniego używania usługi AuthenticationStateProvider jest fakt, że składnik nie jest automatycznie powiadamiany w przypadku zmiany podstawowych danych o stanie uwierzytelnienia.

Aby zaimplementować niestandardowy AuthenticationStateProvider, zobacz ASP.NET Core Blazor stan uwierzytelniania, który zawiera instrukcje implementacji powiadomień o zmianie stanu uwierzytelniania użytkownika.

Uzyskiwanie danych zasad roszczeń użytkownika.

Usługa AuthenticationStateProvider może dostarczyć dane bieżącego użytkownika ClaimsPrincipal , jak pokazano w poniższym przykładzie.

ClaimsPrincipalData.razor:

@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.";
        }
    }
}

W powyższym przykładzie:

• ClaimsPrincipal.Claims Zwraca oświadczenia użytkownika (claims) dla wyświetlania w interfejsie użytkownika.
• Wiersz, który uzyskuje nazwisko użytkownika (surname) wywołuje ClaimsPrincipal.FindAll z predykatem w celu filtrowania roszczeń użytkownika.

Jeśli parametr user.Identity.IsAuthenticated ma wartość true, ponieważ użytkownik jest obiektem ClaimsPrincipal, można wyliczyć oświadczenia i ocenić członkostwo w rolach.

Aby uzyskać więcej informacji na temat usług i wstrzykiwania zależności, zobacz Wstrzykiwanie zależności Blazor w środowisku ASP.NET Core i Wstrzykiwanie zależności w środowisku ASP.NET Core. Aby uzyskać informacje na temat implementowania niestandardowego AuthenticationStateProvider, zobacz ASP.NET Core Blazor stan uwierzytelniania.

Uwidacznianie stanu uwierzytelnienia jako parametru kaskadowego

Jeśli dane stanu uwierzytelniania są wymagane dla logiki proceduralnej, takiej jak podczas wykonywania akcji wyzwalanej przez użytkownika, uzyskaj dane stanu uwierzytelniania, definiując kaskadowy parametr typu Task<AuthenticationState>, jak pokazano w poniższym przykładzie.

CascadeAuthState.razor:

@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.";
            }
        }
    }
}

Jeśli parametr user.Identity.IsAuthenticated ma wartość true, można wyliczyć roszczenia i ocenić członkostwo w rolach.

Skonfiguruj parametr kaskadowy korzystając z usług stanu uwierzytelniania kaskadowego .

Podczas tworzenia aplikacji Blazor z jednego z szablonów projektów Blazor z włączonym uwierzytelnianiem, aplikacja zawiera AuthorizeRouteView oraz wywołanie AddCascadingAuthenticationState pokazane w poniższym przykładzie. Aplikacja po stronie klienta Blazor zawiera również wymagane rejestracje usług. Dodatkowe informacje są przedstawione w sekcji Dostosowywanie nieautoryzowanej zawartości za pomocą składnika Router.

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

W pliku Program zarejestruj usługi stanu uwierzytelniania kaskadowego:

builder.Services.AddCascadingAuthenticationState();

W aplikacji po stronie Blazor klienta dodaj usługi autoryzacji do Program pliku:

builder.Services.AddAuthorizationCore();

W aplikacji po stronie Blazor serwera usługi dla opcji i autoryzacji są już obecne, więc nie są wymagane żadne dalsze kroki.

Autoryzacja

Po uwierzytelnieniu użytkownika stosowane są reguły autoryzacji, określające, co ten użytkownik może robić.

O udzieleniu lub odmowie dostępu decydują następujące czynniki:

• Uwierzytelnienie (zalogowanie) użytkownika.
• Użytkownik jest w roli.
• Użytkownik ma roszczenie.
• Spełnienie zasad.

Każda z tych koncepcji jest taka sama jak w przypadku aplikacji platformy ASP.NET Core, zarówno MVC, jak i Razor Pages. Aby uzyskać więcej informacji na temat zabezpieczeń platformy ASP.NET Core, zobacz artykuły wymienione w sekcji ASP.NET Core Security and Identity.

AuthorizeView komponent

Składnik AuthorizeView selektywnie wyświetla zawartość interfejsu użytkownika w zależności od tego, czy użytkownik jest autoryzowany. Takie podejście jest przydatne, gdy wystarczy wyświetlić dane użytkownikowi i nie trzeba używać tożsamości użytkownika w logice proceduralnej.

Składnik uwidacznia zmienną context typu AuthenticationState (@context w Razor składni), której można użyć do uzyskiwania dostępu do informacji o zalogowanym użytkowniku:

<AuthorizeView>
    <p>Hello, @context.User.Identity?.Name!</p>
</AuthorizeView>

Możesz również podać inną zawartość do wyświetlania, jeśli użytkownik nie jest autoryzowany za pomocą kombinacji parametrów Authorized i NotAuthorized :

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
        <p><button @onclick="HandleClick">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    private void HandleClick() { ... }
}

AuthorizeView Mimo że składnik kontroluje widoczność elementów na podstawie stanu autoryzacji użytkownika, nie wymusza zabezpieczeń w samej procedurze obsługi zdarzeń. W poprzednim przykładzie HandleClick metoda jest skojarzona tylko z przyciskiem widocznym dla autoryzowanych użytkowników, ale nic nie uniemożliwia wywołania tej metody z innych miejsc. Aby zapewnić bezpieczeństwo na poziomie metody, zaimplementuj dodatkową logikę autoryzacji w ramach samego programu obsługi lub w odpowiednim interfejsie API.

Razorskładniki Blazor Web Apps nigdy nie wyświetlają <NotAuthorized> zawartości, gdy autoryzacja kończy się niepowodzeniem po stronie serwera podczas renderowania statycznego po stronie serwera (statyczne SSR). Potok po stronie serwera ASP.NET Core przeprowadza autoryzację na serwerze. Użyj technik po stronie serwera do obsługi nieautoryzowanych żądań. Aby uzyskać więcej informacji, zobacz tryby renderowania Blazor ASP.NET Core.

Ostrzeżenie

Znaczniki i metody skojarzone z elementem AuthorizeView po stronie klienta są chronione tylko przed wyświetlaniem i wykonywaniem w renderowanych interfejsach użytkownika w aplikacjach po stronie Blazor klienta. Aby chronić autoryzowaną zawartość i bezpieczne metody po stronie Blazor klienta, zawartość jest zwykle dostarczana przez bezpieczne, autoryzowane wywołanie web API do serwerowego API i nigdy nie jest przechowywana w aplikacji. Aby uzyskać więcej informacji, zobacz Wywoływanie interfejsu API sieciowego z aplikacji ASP.NET CoreBlazor oraz Dodatkowe scenariusze zabezpieczeń w ASP.NET CoreBlazor WebAssembly.

Zawartość elementów Authorized i NotAuthorized może zawierać dowolne elementy, takie jak inne składniki interaktywne.

Warunki autoryzacji, takie jak role i zasady używane do zarządzania dostępem i opcjami interfejsu użytkownika, omówiono w sekcji Autoryzacja.

Jeśli nie określono warunków autoryzacji, AuthorizeView użyj zasad domyślnych:

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Składnika AuthorizeView można używać w składniku NavMenu (Shared/NavMenu.razor) w celu wyświetlania składnika NavLink (NavLink), należy jednak zauważyć, że to rozwiązanie umożliwia jedynie usunięcie elementu listy z przedstawionych danych wyjściowych. Nie uniemożliwia użytkownikowi przejścia do składnika. Zaimplementuj autoryzację oddzielnie w składniku docelowym.

Autoryzacja oparta na rolach i politykach

Składnik AuthorizeView obsługuje autoryzację na podstawie ról lub zasad.

W przypadku autoryzacji opartej na rolach użyj parametru Roles . W poniższym przykładzie użytkownik musi mieć oświadczenie dotyczące roli dla ról Admin lub Superuser.

<AuthorizeView Roles="Admin, Superuser">
    <p>You have an 'Admin' or 'Superuser' role claim.</p>
</AuthorizeView>

Aby wymagać, by użytkownik posiadał oświadczenia ról zarówno Admin jak i Superuser, zagnieżdż składniki AuthorizeView.

<AuthorizeView Roles="Admin">
    <p>User: @context.User</p>
    <p>You have the 'Admin' role claim.</p>
    <AuthorizeView Roles="Superuser" Context="innerContext">
        <p>User: @innerContext.User</p>
        <p>You have both 'Admin' and 'Superuser' role claims.</p>
    </AuthorizeView>
</AuthorizeView>

Powyższy kod ustanawia element Context dla składnika wewnętrznego AuthorizeView , aby zapobiec AuthenticationState kolizji kontekstu. Dostęp do AuthenticationState kontekstu można uzyskać na zewnątrz AuthorizeView za pomocą standardowego podejścia do uzyskiwania kontekstu (@context.User). Do kontekstu uzyskuje się dostęp w wewnętrznym AuthorizeView z nazwanym innerContext kontekstem (@innerContext.User).

Aby uzyskać więcej informacji, w tym wskazówki dotyczące konfiguracji, zobacz Autoryzacja na podstawie ról na platformie ASP.NET Core.

W przypadku autoryzacji opartej na zasadach użyj parametru Policy z pojedynczą nazwą zasad:

<AuthorizeView Policy="Over21">
    <p>You satisfy the 'Over21' policy.</p>
</AuthorizeView>

Aby obsłużyć przypadek, w którym użytkownik powinien spełnić jedną z kilku zasad, utwórz zasady, które potwierdzają, że użytkownik spełnia inne zasady.

Aby obsłużyć przypadek, w którym użytkownik musi spełnić kilka zasad jednocześnie, wykonaj jedną z następujących metod:

• Utwórz politykę dla AuthorizeView, która potwierdza, że użytkownik spełnia kilka innych polityk.

• Zagnieżdżaj zasady w wielu AuthorizeView składnikach:

  <AuthorizeView Policy="Over21">
      <AuthorizeView Policy="LivesInCalifornia">
          <p>You satisfy the 'Over21' and 'LivesInCalifornia' policies.</p>
      </AuthorizeView>
  </AuthorizeView>
  

Autoryzacja na podstawie oświadczeń to szczególny przypadek autoryzacji na podstawie zasad. Można na przykład zdefiniować zasady, które wymagają od użytkowników posiadania określonego oświadczenia. Aby uzyskać więcej informacji, zobacz Autoryzacja na podstawie zasad na platformie ASP.NET Core.

Jeśli ani Roles, ani Policy nie zostaną określone, AuthorizeView korzysta z domyślnej zasady.

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Ponieważ w porównaniach ciągów platformy .NET uwzględniane są wielkości liter, dopasowywanie się nazw ról i zasad jest również uwzględniane z uwagi na wielkość liter. Na przykład Admin (wielkie litery A) nie jest traktowana jako ta sama rola co admin (małe litery a).

Przypadek Pascal jest zwykle używany dla nazw ról i zasad (na przykład BillingAdministrator), ale użycie przypadku Pascal nie jest ścisłym wymaganiem. Różne schematy wielkości liter, takie jak przypadek wielbłąda, przypadek kebab i przypadek węża, są dozwolone. Używanie spacji w nazwach ról i zasad jest nietypowe, ale dozwolone przez platformę. Na przykład billing administrator jest to nietypowy format nazwy roli lub zasad w aplikacjach platformy .NET, ale jest to prawidłowa nazwa roli lub zasad.

Zawartość wyświetlana podczas uwierzytelniania asynchronicznego

Struktura Blazor umożliwia asynchroniczne określanie stanu uwierzytelnienia. Podstawowym scenariuszem tego podejścia są aplikacje po stronie Blazor klienta, które wysyłają żądanie do zewnętrznego punktu końcowego na potrzeby uwierzytelniania.

W trakcie uwierzytelniania AuthorizeView nie wyświetla żadnej zawartości. Aby wyświetlić zawartość podczas uwierzytelniania, przypisz zawartość do parametru Authorizing :

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <Authorizing>
        <p>You can only see this content while authentication is in progress.</p>
    </Authorizing>
</AuthorizeView>

Takie podejście nie ma zwykle zastosowania do aplikacji po stronie Blazor serwera. Aplikacje działające po stronie Blazor serwera są świadome stanu uwierzytelniania od razu po jego ustanowieniu. Authorizing zawartość może być dostarczana w składniku AuthorizeView aplikacji, ale ta zawartość nigdy nie jest wyświetlana.

Atrybut [Authorize]

Atrybut [Authorize] jest dostępny w Razor składnikach:

@page "/"
@attribute [Authorize]

You can only see this if you're signed in.

Ważne

Używaj [Authorize] tylko na komponentach @page osiąganych za pośrednictwem routera Blazor. Autoryzacja jest przeprowadzana tylko jako aspekt routingu i nie dotyczy składników podrzędnych renderowanych na stronie. Aby autoryzować wyświetlanie konkretnych części strony, należy użyć składnika AuthorizeView.

Atrybut [Authorize] także obsługuje autoryzację na podstawie ról lub zasad. W przypadku autoryzacji na podstawie ról należy użyć parametru Roles:

@page "/"
@attribute [Authorize(Roles = "Admin, Superuser")]

<p>You can only see this if you're in the 'Admin' or 'Superuser' role.</p>

W przypadku autoryzacji na podstawie zasad należy użyć parametru Policy:

@page "/"
@attribute [Authorize(Policy = "Over21")]

<p>You can only see this if you satisfy the 'Over21' policy.</p>

Jeśli ani Roles, ani Policy nie są określone, [Authorize] stosuje domyślną zasadę:

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Gdy użytkownik nie jest autoryzowany i jeśli aplikacja nie dostosowuje nieautoryzowanego dostępu ze składnikiem Router, platforma automatycznie wyświetla następujący komunikat awaryjny:

Not authorized.

Autoryzacja zasobów

Aby autoryzować użytkowników na potrzeby dostępu do zasobów, należy przekazać dane trasy żądania do parametru Resource składnika AuthorizeRouteView.

W treści dotyczącej żądanej trasy Router.Found:

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

Aby uzyskać więcej informacji na temat sposobu przekazywania danych o stanie autoryzacji i używania ich w logice proceduralnej, zobacz sekcję Uwidacznianie stanu uwierzytelnienia jako parametru kaskadowego.

Gdy AuthorizeRouteView odbierze dane dotyczące trasy dla zasobu, zasady autoryzacji mają dostęp do RouteData.PageType i RouteData.RouteValues, co pozwala na zastosowanie logiki niestandardowej do podejmowania decyzji dotyczących autoryzacji.

W poniższym przykładzie utworzono zasadę EditUser w usłudze AuthorizationOptions na potrzeby konfiguracji usługi autoryzacji dla aplikacji (AddAuthorizationCore), z następującą logiką:

• Sprawdź, czy istnieje wartość ścieżki z kluczem id. Jeśli ten klucz istnieje, wartość trasy jest zapisywana jako value.
• W zmiennej o nazwie id wartość value jest zapisywana jako ciąg lub jest ustawiana pusta wartość ciągu (string.Empty).
• Jeśli zmienna id nie zawiera pustego ciągu, należy stwierdzić, że zasady są spełnione (zwrócić wartość true), jeśli wartość ciągu zaczyna się od EMP. W przeciwnym razie należy stwierdzić, że zasady nie są spełnione (zwrócić wartość false).

W pliku Program:

• Dodaj przestrzenie nazw Microsoft.AspNetCore.Components i System.Linq:

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

• Dodaj zasady:

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

Powyższy przykład przedstawia bardzo uproszczone zasady autoryzacji, służące wyłącznie do zilustrowania tej koncepcji przy użyciu działającego przykładu. Aby uzyskać więcej informacji na temat tworzenia i konfigurowania zasad autoryzacji, zobacz Autoryzacja na podstawie zasad na platformie ASP.NET Core.

W poniższym składniku EditUser zasób w pozycji /users/{id}/edit zawiera parametr trasy dla identyfikatora użytkownika ({id}). Ten składnik używa poprzednich zasad autoryzacji EditUser do określenia, czy wartość trasy dla zmiennej id zaczyna się od EMP. Jeśli zmienna id zaczyna się od EMP, zasady są spełnione i dostęp do składnika jest autoryzowany. Jeśli zmienna id zaczyna się od wartości innej niż EMP lub jeśli zmienna id zawiera pusty ciąg, zasady nie są spełnione, a składnik nie zostanie załadowany.

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

Dostosowywanie nieautoryzowanej zawartości za pomocą Router składnika

Składnik Router w połączeniu ze składnikiem AuthorizeRouteView umożliwia określenie zawartości niestandardowej w aplikacji, gdy:

• Użytkownik nie spełnia warunku [Authorize] zastosowanego do składnika. Są wyświetlane znaczniki elementu <NotAuthorized>. Atrybut [Authorize] jest omówiony w sekcji atrybut [Authorize].
• Autoryzacja asynchroniczna jest w toku, co zwykle oznacza, że trwa proces uwierzytelniania użytkownika. Są wyświetlane znaczniki elementu <Authorizing>.

Ważne

Blazor funkcje routera, które wyświetlają <NotAuthorized> i <NotFound> zawartość, nie działają podczas statycznego renderowania po stronie serwera (statyczne SSR), ponieważ przetwarzanie żądań jest w pełni obsługiwane przez algorytm pośredniczący ASP.NET Core i Razor składniki w ogóle się nie renderują dla nieautoryzowanych lub nieprawidłowych żądań. Użyj technik po stronie serwera, aby obsługiwać nieautoryzowane i nieprawidłowe żądania podczas statycznego rejestrowania SSR. Aby uzyskać więcej informacji, zobacz tryby renderowania ASP.NET Core Blazor.

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

Zawartość elementów Authorized i NotAuthorized może zawierać dowolne elementy, takie jak inne składniki interaktywne.

Uwaga

Aby to osiągnąć, wymagane jest przeprowadzenie kaskadowej rejestracji usług stanu uwierzytelniania w pliku aplikacji Program.

builder.Services.AddCascadingAuthenticationState();

Jeśli NotAuthorized zawartość nie zostanie określona, zostanie użyta AuthorizeRouteView następująca wiadomość rezerwowa:

Not authorized.

Aplikacja utworzona na podstawie szablonu projektu Blazor WebAssembly z włączonym uwierzytelnianiem zawiera składnik RedirectToLogin, który jest umieszczony w zawartości <NotAuthorized> składnika Router. Gdy użytkownik nie jest uwierzytelniony (context.User.Identity?.IsAuthenticated != true), RedirectToLogin składnik przekierowuje przeglądarkę do punktu końcowego authentication/login na potrzeby uwierzytelniania. Użytkownik jest zwracany do żądanego adresu URL po uwierzytelnieniu za pomocą dostawcy tożsamości.

Logika proceduralna

Jeśli aplikacja musi sprawdzić reguły autoryzacji w ramach logiki proceduralnej, użyj kaskadowego parametru typu Task<AuthenticationState>, aby uzyskać dane ClaimsPrincipal użytkownika. Parametr Task<AuthenticationState> można połączyć z innymi usługami, takimi jak IAuthorizationService, w celu oceny zasad.

W poniższym przykładzie:

• Funkcja user.Identity.IsAuthenticated wykonuje kod dla uwierzytelnionych (zalogowanych) użytkowników.
• user.IsInRole("admin") wykonuje kod dla użytkowników w roli „Administrator”.
• Element (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded wykonuje kod dla użytkowników spełniających politykę "content-editor".

Aplikacja po stronie Blazor serwera zawiera odpowiednie przestrzenie nazw utworzone na podstawie szablonu projektu. W aplikacji klienta po stronie Blazor potwierdź obecność tych przestrzeni nazw: Microsoft.AspNetCore.Authorization oraz Microsoft.AspNetCore.Components.Authorization w składniku lub w pliku aplikacji _Imports.razor.

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

ProceduralLogic.razor:

@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)
                {
                    // ...
                }
            }
        }
    }
}

Rozwiązywanie problemów

Typowe błędy:

• Autoryzacja wymaga parametru kaskadowego typu Task<AuthenticationState>. Rozważ użycie CascadingAuthenticationState do zapewnienia tego.

• Wartość null odbierana dla elementu authenticationStateTask

Prawdopodobnie projekt nie został utworzony przy użyciu szablonu po stronie Blazor serwera z włączonym uwierzytelnianiem.

Na platformie .NET 7 lub starszej obejmij część drzewa interfejsu użytkownika, na przykład wokół routera .

<CascadingAuthenticationState>
    <Router ...>
        ...
    </Router>
</CascadingAuthenticationState>

Nie używaj składnika CascadingAuthenticationState w programie .NET 8 lub nowszym.

- <CascadingAuthenticationState>
      <Router ...>
          ...
      </Router>
- </CascadingAuthenticationState>

Zamiast tego dodaj kaskadowe usługi stanu uwierzytelniania do kolekcji usług w pliku Program.

builder.Services.AddCascadingAuthenticationState();

Składnik CascadingAuthenticationState (.NET 7 lub starszy) lub usługi udostępniane przez AddCascadingAuthenticationState (.NET 8 lub nowszy) dostarczają Task<AuthenticationState> parametr kaskadowy, który z kolei otrzymuje z bazowej usługi wstrzykiwania zależności AuthenticationStateProvider.

Dane osobowe (PII)

Firma Microsoft używa definicji RODO dla "danych osobowych" (RODO 4.1), gdy w dokumentacji omówiono dane osobowe (PII).

Dane osobowe dotyczą wszelkich informacji dotyczących zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. Możliwa do zidentyfikowania osoba fizyczna to osoba, która może zostać zidentyfikowana bezpośrednio lub pośrednio z dowolną z następujących czynności:

• Nazwisko
• Numer identyfikacyjny
• Współrzędne lokalizacji
• Identyfikator online
• Inne konkretne czynniki
  • Fizyczne
  • Fizjologiczne
  • Genetyka
  • Mentalny (psychologiczny)
  • Ekonomiczny
  • Kulturalny
  • Tożsamość społecznościowa

Dodatkowe zasoby

• Zasoby po stronie serwera i Blazor Web App
  • Szybki start: dodawanie logowania przy użyciu konta Microsoft do aplikacji internetowej platformy ASP.NET Core
  • Szybki start: ochrona internetowego interfejsu API platformy ASP.NET Core przy użyciu platformy tożsamości firmy Microsoft
  • Konfigurowanie ASP.NET Core do pracy z serwerami proxy i modułami równoważenia obciążenia: zawiera wskazówki dotyczące:
    • Używanie Forwarded Headers Middleware, aby zachować informacje o schemacie HTTPS między serwerami proxy i sieciami wewnętrznymi.
    • Dodatkowe scenariusze i przypadki użycia, w tym ręczna konfiguracja schematu, żądanie zmiany ścieżki żądania na potrzeby prawidłowego routingu żądań i przekazywanie schematu żądań dla zwrotnych serwerów proxy systemu Linux i innych niż IIS.
• Dokumentacja platformy tożsamości firmy Microsoft
  • Omówienie
  • protokoły OAuth 2.0 i OpenID Connect na platformie tożsamości firmy Microsoft
  • platforma tożsamości Microsoft i przepływ kodu autoryzacyjnego OAuth 2.0
  • Tokeny ID platformy tożsamości Microsoft
  • tokeny dostępu platformy tożsamości firmy Microsoft
• Tematy dotyczące zabezpieczeń platformy ASP.NET Core
• Konfigurowanie uwierzytelniania systemu Windows na platformie ASP.NET Core
• IHttpContextAccessor/HttpContext w aplikacjach ASP.NET Core Blazor
• Tworzenie niestandardowej wersji biblioteki JavaScript Authentication.MSAL
• Awesome Blazor: Authentication — linki do przykładów od społeczności
• Uwierzytelnianie i autoryzacja w aplikacjach Blazor Hybrid na platformie ASP.NET Core