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ę wyłącznie na renderowaniu po stronie serwera (SSR) w celu kontroli autoryzacji i egzekwowania reguł.

Razor Konwencje autoryzacji stron nie mają zastosowania do składników routingu Razor . Jeśli nienawracalny komponent jest osadzony na stronie aplikacji Pages, konwencje autoryzacji strony pośrednio wpływają na ten komponent wraz z resztą zawartości strony.

Uwaga

Przykłady kodu w tym artykule przyjmują typy odwołań dopuszczających wartość null (NRT) 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 celowania w platformę .NET 5 lub starszą usuń oznaczenie typu null (?) z przykładów w tym artykule.

Bezpieczne utrzymywanie poufnych danych i poświadczeń

Nie przechowuj wpisów tajnych aplikacji, parametrów połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu .NET/C# ani prywatnych kluczy/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łszerzami przez wywołanie UseAntiforgery w potoku przetwarzania żądań w Program pliku i wymaga ochrony przed złośliwym kodem punktu końcowego w celu ograniczenia zagrożeń fałszerzowania żą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

pl-PL: Przeciwdziałanie fałszerstwom jest wymagane tylko podczas przesyłania danych formularza do serwera z kodowaniem jako application/x-www-form-urlencoded, multipart/form-data, lub text/plain, ponieważ są to jedyne prawidłowe typy formularzy.

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 głównym artykułem ASP.NET Core na ten temat, który odnosi się do serwera po stronie Blazor Server, projektu serwera Blazor Web App oraz integracji Blazor z MVC/Razor Pages.
• omówienie formularzy ASP.NET CoreBlazor: sekcja pomocy technicznej dotycząca ochrony przed fałszerzami artykułu dotyczy Blazor obsługi ochrony przed fałszerzami 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 temacie ASP.NET Podstawowe tematy dotyczące zabezpieczeń.

Kontekst uwierzytelniania jest ustanawiany tylko po uruchomieniu aplikacji, czyli wtedy, gdy aplikacja najpierw łączy się z protokołem WebSocket za pośrednictwem połączenia z klientemSignalR. Uwierzytelnianie może być oparte na tokenie dostępu cookie lub innym tego rodzaju tokenie, ale 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 na serwerze, które tworzą nowe żądania HTTP z plikami cookie w każdej nawigacji strony. 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 uwierzytelnienia użytkownika jest sprawdzany w układzie 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 (NRT) 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 pracy z platformą .NET 5 lub starszą 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 Core Blazor authentication and authorization (Uwierzytelnianie i autoryzacja podstawowe).

Współdzielony stan

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 Zarządzanie stanem podstawowymBlazor.

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ę serwera Blazor postępując zgodnie ze wskazówkami w Tooling for ASP.NET Core Blazor.

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 (Interfejs wiersza polecenia .NET)

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

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 symbol zastępczy {PROJECT TEMPLATE} 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 pakietów Identity w _Imports.razor.
• Tworzy niestandardową klasę użytkownika Identity (ApplicationUser).
• Tworzy i rejestruje EF Core kontekst bazy danych (ApplicationDbContext).
• Konfiguruje trasowanie dla wbudowanych Identity punktów końcowych.
• Obejmuje Identity walidację i logikę biznesową.

Aby sprawdzić Blazor składniki platformyIdentity, uzyskaj do nich dostęp w Pages i Shared katalogach folderu Account w szablonie projektu Blazor Web App (źródła odniesienia).

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 na serwerze, jak i na kliencie (.Client), aby przekazywać stan 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 używają usługi stanu trwałego składnika do serializacji stanu uwierzytelniania w komentarzach HTML, a następnie odczytują go z powrotem za pomocą WebAssembly, aby utworzyć nowe wystąpienie . Aby uzyskać więcej informacji, zobacz sekcję Zarządzanie stanem uwierzytelniania w Blazor Web Appsekcji s .

Tylko w przypadku rozwiązań Interactive Server IdentityRevalidatingAuthenticationStateProvider po stronie serwera AuthenticationStateProvider, które ponownie weryfikuje sygnaturę zabezpieczeń dla połączonego użytkownika co 30 minut trwania połączenia interaktywnego.

Blazor Identity zależy DbContext od wystąpień, które nie są tworzone przez fabrykę, co jest zamierzone, ponieważ DbContext jest wystarczające, aby składniki szablonu Identity projektu były renderowane statycznie bez obsługi interakcyjności.

Aby zapoznać się z opisem sposobu stosowania globalnych trybów renderowania interaktywnego do komponentów innych niż Identity, przy jednoczesnym wymuszaniu statycznego renderowania SSR dla komponentów Identity, zobacz tryby renderowania ASP.NET CoreBlazor.

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 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 ():

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 Program, co dodaje AddAuthenticationStateDeserialization, w której AuthenticationStateProvider jest deserializowane z serwera przy użyciu usługi Trwały stan składnika (AuthenticationStateAuthenticationStateData). 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, sprawdź Utrwalanie dodatkowych oświadczeń i tokenów od dostawców zewnętrznych w 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żyj Identity do zabezpieczenia backendu Web API 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 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 przewodnik na temat OwningComponentBaseiniekcji zależności w ASP.NET CoreBlazor.

Wyświetlanie nieautoryzowanej zawartości podczas wstępnego renderowania 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: Aby zapoznać się z przykładową implementacją IHostEnvironmentAuthenticationStateProvider, zobacz implementację Blazor platformy ServerAuthenticationStateProvider w ServerAuthenticationStateProvider.cs (źródle referencyjnym).

  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 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 w aplikacjach 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 Blazor.

Dodatkowe abstrakcje zabezpieczeń

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

• ServerAuthenticationStateProvider (źródło referencyjne): Element AuthenticationStateProvider 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 interwał ponownej kontroli 30 minut można dostosować wRevalidatingIdentityAuthenticationStateProvider (źródle odwołania). 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 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 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 proaktywnie wylogować użytkownika na kartach przeglądarki, gdy użytkownik wyloguje się na jednej karcie, musisz zaimplementować RevalidatingServerAuthenticationStateProvider (źródło referencyjne) z krótkim RevalidationInterval.

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 ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Czas trwania ważności tymczasowego adresu URL przekierowania

Ta sekcja dotyczy Blazor Web Apps.

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ć wskazówki dotyczące dodawania pakietów do aplikacji platformy .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w artykule Przepływ pracy użycia pakietów (dokumentacja NuGet). Potwierdź prawidłowe wersje pakietów w NuGet.org.

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

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

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

W przypadku, gdy Blazor Web App wdrożone jest renderowanie po stronie serwera (SSR) oraz renderowanie po stronie klienta (CSR) dla składników lub całej aplikacji, która określa tryb renderowania interakcyjnego Auto, autoryzacja dostępu do składników i danych jest stosowana w dwóch miejscach. 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 pomocą punktów końcowych 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. Demonstracje niektórych z poniższych podejść można ocenić i przetestować przy użyciu BlazorWebAppEntra/BlazorWebAppEntraBffprzykładów (.NET 9 lub nowszych) lub BlazorWebAppOidc/BlazorWebAppOidcBff przykładów (.NET 8 lub nowszych) w repozytorium GitHub Blazor przykładów (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 projektu klienta ClientWeatherForecaster 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 Persistent Component State (PersistentComponentState), aby zachować dane prognozy pogody, gdy składnik przechodzi ze statycznego do interaktywnego SSR na serwerze. Aby uzyskać więcej informacji, zobacz Razor.

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

Projekt serwera implementuje IWeatherForecaster jako ServerWeatherForecaster, który generuje i zwraca dane pogodowe za pomocą metody 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();
    }
}

Jeśli aplikacja musi wywołać zewnętrzny internetowy interfejs API w celu uzyskania danych pogodowych, możesz wstrzyknąć klienta HTTP (HttpClient), aby zażądać danych:

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

W innym podejściu można wstrzyknąć fabrykę klienta HTTP (IHttpClientFactory) do ServerWeatherForecaster i wywołać zewnętrzne API sieciowe, używając nazwanego klienta HTTP z obsługą tokenów. Aby uzyskać więcej informacji, zobacz Wywoływanie interfejsu API z aplikacji ASP.NET Core.

Jeśli aplikacja używa platformy tożsamości Microsoft z pakietami Web MicrosoftIdentity dla Microsoft Entra ID (zobacz Wywoływanie internetowego interfejsu API z aplikacji ASP.NET CoreBlazor), poniżej ServerWeatherForecaster przedstawiono przykład wykonywania zewnętrznego wywołania internetowego interfejsu API. Token dostępu jest automatycznie dołączany do żądania.

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

Niezależnie od podejścia, jakie ServerWeatherForecaster stosuje do uzyskiwania danych, projekt serwera utrzymuje bezpieczny punkt końcowy API dla wywołań danych pogodowych klienta. Ten punkt końcowy powoduje wywołanie ServerWeatherForecaster.GetWeatherForecastAsync na serwerze:

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:

• Weather Gdy składnik jest renderowany na serwerze, ServerWeatherForecaster metoda usługi GetWeatherForecastAsync jest używana bezpośrednio do uzyskiwania danych pogodowych. Bezpieczeństwo danych jest wymuszane przez atrybut składnika[Authorize]. Podsumowując, bezpieczeństwo danych pogodowych jest zapewniane przez składnik.
• Gdy Weather składnik jest renderowany na kliencie, ClientWeatherForecaster usługa jest używana do wykonywania wywołania internetowego interfejsu 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 Blazor repozytorium GitHub () (dotnet/blazor-samplessposób pobierania), które demonstrują podejście opisane w tej sekcji:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

AuthenticationStateProvider Usługa

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

Zazwyczaj nie używa się usługi AuthenticationStateProvider bezpośrednio. Użyj AuthorizeView składnika lub Task<AuthenticationState> podejść 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 wskazówki dotyczące implementowania 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) do wyświetlania w interfejsie użytkownika.
• Linia, która uzyskuje nazwisko użytkownika (surname), wywołuje ClaimsPrincipal.FindAll z predykatem do filtrowania atrybutów 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 wstrzykiwania zależności (DI) i usług, zobacz Blazor i Wstrzykiwanie zależności w ASP.NET Core. Aby uzyskać informacje na temat implementowania niestandardowego AuthenticationStateProviderelementu, 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 zawartości nieautoryzowanej przy użyciu 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 reguły autoryzacji są stosowane do kontrolowania możliwości użytkownika.

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

• Uwierzytelnienie (zalogowanie) użytkownika.
• Użytkownik jest w roli.
• Użytkownik ma oświadczenie.
• Zasady są spełnione.

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ń ASP.NET Core, zobacz artykuły w temacie 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 trzeba tylko wyświetlać dane dla użytkownika i nie musi 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 ASP.NET CoreBlazor.

Ostrzeżenie

Znaczniki i metody związane z elementem AuthorizeView na stronie klienta są chronione przed wyświetlaniem i wykonywaniem tylko w renderowanym interfejsie użytkownika w aplikacjach działających po stronie 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 internetowego interfejsu API z aplikacji ASP.NET Core Blazor i ASP.NET Core Blazor WebAssembly dodatkowych scenariuszy zabezpieczeń.

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

Warunki autoryzacji, takie jak role lub zasady kontrolujące opcje interfejsu użytkownika lub dostęp, są omówione 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ładnik AuthorizeView może być używany w składniku NavMenu (Shared/NavMenu.razor), aby wyświetlić składnik NavLink (NavLink), ale należy pamiętać, że to podejście usuwa tylko element listy z wyniku renderowania. 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ę opartą na rolach lub na podstawie 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 oparta na rolach w programie 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 oparta na zasadach w programie ASP.NET Core.

Jeśli zarówno Roles jak i Policy są ustawione, autoryzacja powiedzie się tylko wtedy, gdy oba warunki zostaną spełnione. Oznacza to, że użytkownik musi należeć do co najmniej jednej z określonych ról i spełniać wymagania zdefiniowane przez zasady.

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 style notacji, takie jak camel case, kebab case i snake case, 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

Blazor umożliwia asynchroniczne określenie stanu uwierzytelniania. 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 wykonywana tylko jako aspekt routingu, a nie dla 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] obsługuje również autoryzację opartą na rolach lub na podstawie 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 zostaną określone, [Authorize] korzysta z domyślnej zasady.

• 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 nieautoryzowanej zawartości ze składnikiemRouter, platforma automatycznie wyświetla następujący komunikat zastępczy:

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 przekazywania i użycia danych stanu autoryzacji w logice proceduralnej, zobacz sekcję Uwidacznianie stanu uwierzytelniania jako kaskadowego parametru .

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, potwierdź, że polityka nie spełnia wymagań (zwróć false).

W pliku Program:

• Dodaj przestrzenie nazw dla 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 oparta na zasadach w programie 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 [Authorize] atrybut.
• 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 SSR. Aby uzyskać więcej informacji, zobacz tryby renderowania ASP.NET CoreBlazor.

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

• null wartość jest odbierana dla 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)
  • Gospodarczy
  • Kultura
  • Tożsamość społecznościowa

Dodatkowe zasoby

• Zasoby po stronie serwera i Blazor Web App
  • Szybki start: dodawanie logowania przy użyciu firmy 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 schematów, zmiany ścieżki żądania dla prawidłowego routowania żądań oraz przekazywanie schematu żądań dla serwerów proxy typu reverse w systemach Linux i innych niż IIS.
• Dokumentacja platformy tożsamości firmy Microsoft
  • Przegląd
  • Protokoły OAuth 2.0 i OpenID Connect na platformie tożsamości firmy Microsoft
  • Platforma tożsamości firmy Microsoft i przepływ kodu autoryzacji OAuth 2.0
  • Tokeny identyfikatorów platformy tożsamości firmy Microsoft
  • Tokeny dostępu platformy tożsamości firmy Microsoft
• ASP.NET Core security topics (Tematy dotyczące zabezpieczeń ASP.NET Core)
• Konfigurowanie uwierzytelniania systemu Windows w programie ASP.NET Core
• IHttpContextAccessor/HttpContext w aplikacjach platformy ASP.NET Core Blazor
• Tworzenie niestandardowej wersji biblioteki Authentication.MSAL JavaScript
• Niesamowite Blazor: przykładowe linki społeczności związanej z uwierzytelnianiem
• Uwierzytelnianie i autoryzacja ASP.NET Core Blazor Hybrid