Zabezpieczanie ASP.NET Core Blazor Web App za pomocą technologii OpenID Connect (OIDC)

W tym artykule opisano, jak zabezpieczyć Blazor Web App za pomocą OpenID Connect (OIDC), korzystając z przykładowej aplikacji w repozytorium dotnet/blazor-samples GitHub (.NET 8 lub nowszy) (jak pobrać).

W tej wersji artykułu omówiono implementację OIDC bez stosowania wzorca Backend for Frontend (BFF) z aplikacją, która wykorzystuje globalne renderowanie interaktywne (projekty serwera i .Client). Wzorzec BFF jest przydatny do podejmowania uwierzytelnionych żądań do usług zewnętrznych. Zmień selektor wersji artykułu na wzorzec BFF, jeśli specyfikacja aplikacji wywołuje wdrożenie wzorca BFF.

Opisano następującą specyfikację:

• Funkcja Blazor Web App używa trybu automatycznego renderowania z globalną interakcyjnością.
• Niestandardowe usługi dostawcy stanu uwierzytelniania są używane przez serwer i aplikacje klienckie do przechwytywania stanu uwierzytelniania użytkownika i przepływu go między serwerem a klientem.
• Ta aplikacja jest punktem wyjścia dla dowolnego przepływu uwierzytelniania OIDC. OIDC jest konfigurowany ręcznie w aplikacji i nie polega na Microsoft Entra ID ani na pakietach Microsoft Identity Web, a przykładowa aplikacja nie wymaga hostingu na Microsoft Azure. Jednak przykładowa aplikacja może być używana z aplikacją Entra, Microsoft Identity Web i hostowaną na platformie Azure.
• Automatyczne odświeżanie tokenu nieinterakcyjnego.
• Bezpiecznie wywołuje (internetowy) interfejs API w projekcie serwera w celu uzyskania danych.

Aby uzyskać alternatywne środowisko korzystania z biblioteki Microsoft Authentication Library for .NET, Microsoft Identity Webi Microsoft Entra ID, zobacz Secure an ASP.NET Core Blazor Web App with Microsoft Entra ID.

Przykładowa aplikacja

Przykładowa aplikacja składa się z dwóch projektów:

• BlazorWebAppOidc: Projekt po stronie serwera systemu Blazor Web App, zawierający przykładowy punkt końcowy Minimal API dla danych pogodowych.
• BlazorWebAppOidc.Client: projekt po stronie klienta obiektu Blazor Web App.

Dostęp do przykładu za pośrednictwem najnowszego folderu wersji w repozytorium przykładów Blazor za pomocą następującego linku. Przykład znajduje się w folderze BlazorWebAppOidc dla platformy .NET 8 lub nowszej.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Projekt serwerowy Blazor Web App (BlazorWebAppOidc)

Projekt BlazorWebAppOidc jest projektem po stronie serwera programu Blazor Web App.

Plik BlazorWebAppOidc.http może służyć do testowania żądania danych pogodowych. Należy pamiętać, że BlazorWebAppOidc projekt musi być uruchomiony, aby przetestować punkt końcowy, a punkt końcowy jest zakodowany w pliku. Aby uzyskać więcej informacji, zobacz Use .http files in Visual Studio 2022 (Używanie plików HTTP w programie Visual Studio 2022).

Konfigurowanie

W tej sekcji wyjaśniono, jak skonfigurować przykładową aplikację.

Uwaga

W przypadku identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C można AddMicrosoftIdentityWebApp używać w witrynie Microsoft Identity Web (Microsoft.Identity.Web pakietu NuGet, dokumentacji interfejsu API), który dodaje zarówno obsługę OIDC, jak i Cookie programy obsługi uwierzytelniania z odpowiednimi wartościami domyślnymi. Przykładowa aplikacja i wskazówki zawarte w tej sekcji nie korzystają z witryny Microsoft Identity Web. Wskazówki pokazują, jak ręcznie skonfigurować procedurę obsługi OIDC dla dowolnego dostawcy OIDC. Aby uzyskać więcej informacji na temat implementowania sieci Web firmy Microsoft Identity , zobacz połączone zasoby.

Ustawienie sekretu klienta

Ostrzeżenie

Nie przechowuj tajnych danych aplikacji, parametrów połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu C#/.NET lub kluczy prywatnych/tokenów w kodzie po stronie klienta, ponieważ jest zawsze niebezpieczny. 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 Bezpieczne utrzymywanie poufnych danych i poświadczeń.

W przypadku lokalnego testowania programistycznego użyj narzędzia Secret Manager do przechowywania tajnego klienta aplikacji serwera w kluczu Authentication:Schemes:MicrosoftOidc:ClientSecret konfiguracji.

Uwaga

Jeśli aplikacja używa Microsoft Entra ID lub Azure AD B2C, utwórz klucz tajny klienta w rejestracji aplikacji w portalu Entra lub Azure (Zarządzaj>Certyfikaty i tajemnice>Nowy klucz tajemny klienta). Użyj Wartości nowego sekretu w poniższych wskazówkach.

Przykładowa aplikacja nie została zainicjowana dla narzędzia Secret Manager. Użyj powłoki poleceń, takiej jak powłoka poleceń programu PowerShell dla deweloperów w programie Visual Studio, aby wykonać następujące polecenie. Przed wykonaniem polecenia zmień katalog na katalog projektu serwera za pomocą polecenia cd. Polecenie ustawia identyfikator sekretów użytkownika (<UserSecretsId> w pliku projektu aplikacji serwera):

dotnet user-secrets init

Wykonaj następujące polecenie, aby ustawić klucz tajny klienta. Symbol zastępczy {SECRET} to tajny klucz klienta uzyskany z rejestracji aplikacji.

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Jeśli używasz programu Visual Studio, możesz potwierdzić, że wpis tajny został ustawiony, klikając prawym przyciskiem myszy projekt serwera w Eksplorator rozwiązań i wybierając polecenie Zarządzaj wpisami tajnymi użytkownika.

Konfigurowanie aplikacji

Następująca OpenIdConnectOptions konfiguracja znajduje się w pliku projektu Program podczas wywołania AddOpenIdConnect:

• SignInScheme: Ustawia schemat uwierzytelniania odpowiadający oprogramowaniu pośredniczącemu odpowiedzialnemu za przechowywanie tożsamości użytkownika po pomyślnym uwierzytelnieniu. Mechanizm OIDC musi używać schematu logowania utrwalającego poświadczenia użytkownika między żądaniami. Poniższy wiersz jest obecny jedynie na potrzeby demonstracji. W przypadku pominięcia DefaultSignInScheme parametr jest używany jako wartość rezerwowa.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Zakresy dla openid i profile (Scope) (opcjonalnie): Zakresy openid i profile są również konfigurowane domyślnie, ponieważ są one wymagane, aby program obsługi OIDC działał, ale może być konieczne ponowne dodanie tych zakresów, jeśli są one uwzględnione w konfiguracji Authentication:Schemes:MicrosoftOidc:Scope. Aby uzyskać ogólne wskazówki dotyczące konfiguracji, zobacz Konfiguracja w ASP.NET Core i Konfiguracja ASP.NET CoreBlazor.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: Określa, czy tokeny dostępu i odświeżania powinny być przechowywane w AuthenticationProperties po pomyślnej autoryzacji. Ta właściwość jest ustawiona na true, aby token odświeżania był przechowywany na potrzeby nieinterakcyjnego odświeżania tokenu.

  oidcOptions.SaveTokens = true;
  

• Zakres dostępu w trybie offline (Scope): offline_access zakres jest wymagany dla tokenu odświeżania.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Authority i ClientId: Ustawia autorytet i identyfikator klienta dla zapytań OIDC.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Przykład:

  • Organ ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (używa identyfikatora dzierżawy aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Identyfikator klienta ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Przykład autorytetu typu "common" dla platformy Microsoft Azure:

  Dla aplikacji wielodostępnych należy używać "wspólnego" autorytetu. Możesz również użyć "ogólnego" autorytetu dla aplikacji jednotenantowych, ale konieczne jest zastosowanie niestandardowego IssuerValidator, jak pokazano w dalszej części tej sekcji.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: Konfiguruje procedurę obsługi OIDC tak, aby wykonywała tylko przepływ kodu autoryzacji. Niejawne dotacje i przepływy hybrydowe są niepotrzebne w tym trybie. Procedura obsługi OIDC automatycznie żąda odpowiednich tokenów przy użyciu kodu zwróconego z punktu końcowego autoryzacji.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Uwaga

  W konfiguracji rejestracji aplikacji dla niejawnych przyznawania i przepływów hybrydowych w Entra lub witrynie Azure Portal nie zaznaczaj żadnego z pól wyboru w punkcie końcowym autoryzacji, aby zwrócić tokeny dostępu lub tokeny ID.

• MapInboundClaims i konfiguracja NameClaimType i RoleClaimType: Wiele serwerów OIDC używa "name" i "role" zamiast domyślnych ustawień SOAP/WS-Fed w ClaimTypes. Gdy MapInboundClaims jest ustawiona wartość false, program obsługi nie wykonuje mapowań roszczeń, a nazwy roszczeń pochodzące z JWT są używane bezpośrednio przez aplikację. W poniższym przykładzie typ oświadczenia roli jest ustawiany na "roles", który jest odpowiedni dla identyfikatora Entra firmy Microsoft (ME-ID). Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dostawcy tożsamości.

  Uwaga

  MapInboundClaims musi być ustawione na false dla większości dostawców OIDC, co uniemożliwia zmianę nazw oświadczeń.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Konfiguracja ścieżki: Ścieżki muszą być zgodne z identyfikatorem URI przekierowania (ścieżką powrotu logowania) oraz ścieżką przekierowania po wylogowaniu (ścieżką powrotu po wylogowaniu), które zostały skonfigurowane podczas rejestrowania aplikacji u dostawcy OIDC. W portalu Azure ścieżki są konfigurowane w panelu Uwierzytelnianie aplikacji zarejestrowanej. Zarówno ścieżki logowania, jak i wylogowania muszą być zarejestrowane jako URI przekierowania. Wartości domyślne to /signin-oidc i /signout-callback-oidc.

  • CallbackPath: ścieżka żądania w ścieżce podstawowej aplikacji, w której jest zwracany agent użytkownika.

    Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost:{PORT}/signin-oidc

    Uwaga

    Port nie jest wymagany dla localhost adresów w przypadku korzystania z identyfikatora Entra firmy Microsoft. Większość innych dostawców OIDC wymaga poprawnego portu.

  • SignedOutCallbackPath (klucz konfiguracji: "SignedOutCallbackPath"): ścieżka żądania w ścieżce podstawowej aplikacji przechwycona przez program obsługi OIDC, gdzie agent użytkownika jest najpierw zwracany po wylogowaniu się z dostawcy tożsamości. Przykładowa aplikacja nie ustawia wartości dla ścieżki, ponieważ jest używana domyślna wartość "/signout-callback-oidc". Po przechwyceniu żądania, handler OIDC przekierowuje do SignedOutRedirectUri lub RedirectUri, jeśli określono.

    Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost:{PORT}/signout-callback-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw ścieżkę w konfiguracji platformy webowej we wpisach URI przekierowania w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu. Jeśli nie dodasz identyfikatora URI ścieżki wywołania zwrotnego po wylogowaniu do rejestracji aplikacji w Entra, Entra odmawia przekierowania użytkownika z powrotem do aplikacji i prosi jedynie o zamknięcie okna przeglądarki.

  • RemoteSignOutPath: Żądania odebrane na tej ścieżce powodują, że program obsługi wywołuje wylogowywanie przy użyciu schematu wylogowywania.

    W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost/signout-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw adres URL wylogowywania na kanale frontowym w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Przykłady (wartości domyślne):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Platforma Microsoft Azure tylko w przypadku "wspólnego" punktu końcowego): TokenValidationParameters.IssuerValidatorwielu dostawców OIDC współpracuje z domyślnym modułem sprawdzania poprawności wystawcy, ale musimy uwzględnić wystawcę sparametryzowanego przy użyciu identyfikatora dzierżawy ({TENANT ID}) zwróconego przez https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Aby uzyskać więcej informacji, zobacz SecurityTokenInvalidIssuerException z OpenID Connect i punktem końcowym Azure AD "common" (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Tylko w przypadku aplikacji korzystających z identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C z "wspólnym" punktem końcowym:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Przykładowy kod aplikacji

Sprawdź przykładową aplikację pod kątem następujących funkcji:

• Automatyczne odświeżanie tokena bez interakcji przy pomocy niestandardowego cookie odświeżacza (CookieOidcRefresher.cs).
• Projekt serwera wywołuje AddAuthenticationStateSerialization, aby dodać dostawcę stanu uwierzytelniania po stronie serwera, który używa PersistentComponentState do przesyłania stanu uwierzytelniania do klienta. Klient wywołuje AddAuthenticationStateDeserialization w celu deserializacji i użycia stanu uwierzytelniania przekazanego przez serwer. Stan uwierzytelniania jest stały dla okresu istnienia aplikacji WebAssembly.
• Przykładowe żądania dotyczące Blazor Web App danych pogodowych są obsługiwane przez minimalny interfejs API (/weather-forecast) w pliku (Program) (Program.cs). Punkt końcowy wymaga autoryzacji przez wywołanie metody RequireAuthorization. W przypadku wszystkich kontrolerów dodanych do projektu dodaj [Authorize] atrybut do kontrolera lub akcji. Aby uzyskać więcej informacji na temat wymagania autoryzacji w aplikacji za pośrednictwem zasad autoryzacji i pominięcia autoryzacji w przypadku pewnego podzbioru publicznych punktów końcowych, zobacz wskazówki Razor Pages OIDC.
• Aplikacja bezpiecznie wywołuje (internetowy) interfejs API w projekcie serwera na potrzeby danych pogodowych:
  • Podczas renderowania Weather komponentu na serwerze, komponent używa ServerWeatherForecaster na serwerze do uzyskiwania danych pogodowych bezpośrednio (nie za pośrednictwem wywołania internetowego interfejsu API).
  • Gdy składnik jest renderowany na kliencie, używa implementacji usługi ClientWeatherForecaster, która korzysta z wstępnie skonfigurowanego HttpClient (w pliku projektu klienta Program), aby nawiązać połączenie z internetowym interfejsem API w projekcie serwera. Minimalny punkt końcowy interfejsu API (/weather-forecast) zdefiniowany w pliku projektu Program serwera uzyskuje dane pogodowe z ServerWeatherForecaster i zwraca je do klienta.

Aby uzyskać więcej informacji na temat wywołań interfejsu API sieci Web przy użyciu abstrakcji usługi w Blazor Web App, zobacz Wywołaj interfejs API sieci Web z aplikacji ASP.NET Core Blazor.

Projekt po stronie Blazor Web App klienta (BlazorWebAppOidc.Client)

Projekt BlazorWebAppOidc.Client jest projektem po stronie klienta programu Blazor Web App.

Klient wywołuje AddAuthenticationStateDeserialization w celu deserializacji i użycia stanu uwierzytelniania przekazanego przez serwer. Stan uwierzytelniania jest stały dla okresu istnienia aplikacji WebAssembly.

Jeśli użytkownik musi się zalogować lub wylogować, wymagane jest ponowne załadowanie pełnej strony.

Przykładowa aplikacja udostępnia tylko nazwę użytkownika i adres e-mail do celów wyświetlania. Nie obejmuje tokenów uwierzytelniających się na serwerze podczas podejmowania kolejnych żądań, które działają oddzielnie przy użyciu elementu cookie uwzględnionego w HttpClient żądaniach do serwera.

W tej wersji artykułu opisano implementację OIDC bez stosowania wzorca Backend for Frontend (BFF) z aplikacją, która korzysta z globalnego interaktywnego renderowania serwera (jeden projekt). Wzorzec BFF jest przydatny do podejmowania uwierzytelnionych żądań do usług zewnętrznych. Zmień selektor wersji artykułu na wzorzec BFF , jeśli specyfikacja aplikacji przewiduje przyjęcie wzorca BFF z globalnym renderowaniem Interactive Auto.

Opisano następującą specyfikację:

• Blazor Web App używa trybu renderowania serwera z globalną interaktywnością.
• Ta aplikacja jest punktem wyjścia dla dowolnego przepływu uwierzytelniania OIDC. OIDC jest konfigurowany ręcznie w aplikacji i nie polega na Microsoft Entra ID ani na pakietach Microsoft Identity Web, a przykładowa aplikacja nie wymaga hostingu na Microsoft Azure. Jednak przykładowa aplikacja może być używana z aplikacją Entra, Microsoft Identity Web i hostowaną na platformie Azure.
• Automatyczne odświeżanie tokenu nieinterakcyjnego.

Aby uzyskać alternatywne środowisko korzystania z biblioteki Microsoft Authentication Library for .NET, Microsoft Identity Webi Microsoft Entra ID, zobacz Secure an ASP.NET Core Blazor Web App with Microsoft Entra ID.

Przykładowa aplikacja

Przykładowa aplikacja składa się z pojedynczego projektu Blazor Web App po stronie serwera (BlazorWebAppOidcServer).

Dostęp do przykładu za pośrednictwem najnowszego folderu wersji w repozytorium przykładów Blazor za pomocą następującego linku. Przykład znajduje się w folderze BlazorWebAppOidcServer dla platformy .NET 8 lub nowszej.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Konfigurowanie

W tej sekcji wyjaśniono, jak skonfigurować przykładową aplikację.

Uwaga

W przypadku identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C można AddMicrosoftIdentityWebApp używać w witrynie Microsoft Identity Web (Microsoft.Identity.Web pakietu NuGet, dokumentacji interfejsu API), który dodaje zarówno obsługę OIDC, jak i Cookie programy obsługi uwierzytelniania z odpowiednimi wartościami domyślnymi. Przykładowa aplikacja i wskazówki zawarte w tej sekcji nie korzystają z witryny Microsoft Identity Web. Wskazówki pokazują, jak ręcznie skonfigurować procedurę obsługi OIDC dla dowolnego dostawcy OIDC. Aby uzyskać więcej informacji na temat implementowania sieci Web firmy Microsoft Identity , zobacz połączone zasoby.

Ustawienie sekretu klienta

Ostrzeżenie

Nie przechowuj tajnych danych aplikacji, parametrów połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu C#/.NET lub kluczy prywatnych/tokenów w kodzie po stronie klienta, ponieważ jest zawsze niebezpieczny. 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 Bezpieczne utrzymywanie poufnych danych i poświadczeń.

W przypadku lokalnego testowania programistycznego użyj narzędzia Secret Manager, aby przechowywać tajny klucz klienta aplikacji pod kluczem konfiguracji Authentication:Schemes:MicrosoftOidc:ClientSecret.

Uwaga

Jeśli aplikacja używa Microsoft Entra ID lub Azure AD B2C, utwórz klucz tajny klienta w rejestracji aplikacji w portalu Entra lub Azure (Zarządzaj>Certyfikaty i tajemnice>Nowy klucz tajemny klienta). Użyj Wartości nowego sekretu w poniższych wskazówkach.

Przykładowa aplikacja nie została zainicjowana dla narzędzia Secret Manager. Użyj powłoki poleceń, takiej jak powłoka poleceń programu PowerShell dla deweloperów w programie Visual Studio, aby wykonać następujące polecenie. Przed wykonaniem polecenia zmień katalog za pomocą polecenia cd na katalog projektu. Polecenie ustanawia identyfikator tajnych danych użytkownika w pliku projektu aplikacji (<UserSecretsId>):

dotnet user-secrets init

Wykonaj następujące polecenie, aby ustawić klucz tajny klienta. Symbol zastępczy {SECRET} to tajny klucz klienta uzyskany z rejestracji aplikacji.

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Jeśli używasz programu Visual Studio, możesz potwierdzić, że wpis tajny został ustawiony, klikając prawym przyciskiem myszy projekt w eksploratorze rozwiązań i wybierając pozycję Zarządzaj wpisami tajnymi użytkownika.

Konfigurowanie aplikacji

Następująca OpenIdConnectOptions konfiguracja znajduje się w pliku projektu Program podczas wywołania AddOpenIdConnect:

• SignInScheme: Ustawia schemat uwierzytelniania odpowiadający oprogramowaniu pośredniczącemu odpowiedzialnemu za przechowywanie tożsamości użytkownika po pomyślnym uwierzytelnieniu. Procedura obsługi OIDC musi używać schematu logowania, który może zapamiętywać poświadczenia użytkownika między żądaniami. Poniższy wiersz jest obecny jedynie na potrzeby demonstracji. W przypadku pominięcia DefaultSignInScheme parametr jest używany jako wartość rezerwowa.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Zakresy dla openid i profile (Scope) (opcjonalnie): Zakresy openid i profile są również konfigurowane domyślnie, ponieważ są one wymagane, aby program obsługi OIDC działał, ale może być konieczne ponowne dodanie tych zakresów, jeśli są one uwzględnione w konfiguracji Authentication:Schemes:MicrosoftOidc:Scope. Aby uzyskać ogólne wskazówki dotyczące konfiguracji, zobacz Konfiguracja w ASP.NET Core i Konfiguracja ASP.NET CoreBlazor.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: Określa, czy tokeny dostępu i odświeżania powinny być przechowywane w AuthenticationProperties po pomyślnej autoryzacji. Ta właściwość jest ustawiona na true, aby token odświeżania był przechowywany na potrzeby nieinterakcyjnego odświeżania tokenu.

  oidcOptions.SaveTokens = true;
  
  

• Zakres dostępu w trybie offline (Scope): Do uzyskania tokenu odświeżania wymagany jest zakres offline_access.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Authority i ClientId: Ustawia autorytet i identyfikator klienta dla wywołań OIDC.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Przykład:

  • Organ ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (używa identyfikatora dzierżawy aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Identyfikator klienta ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Przykład autorytetu typu "common" dla platformy Microsoft Azure:

  Dla aplikacji wielodostępnych należy używać "wspólnego" autorytetu. Możesz również użyć "ogólnego" autorytetu dla aplikacji jednotenantowych, ale konieczne jest zastosowanie niestandardowego IssuerValidator, jak pokazano w dalszej części tej sekcji.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: Konfiguruje procedurę obsługi OIDC tak, aby wykonywała tylko przepływ kodu autoryzacji. Niejawne dotacje i przepływy hybrydowe są niepotrzebne w tym trybie. Procedura obsługi OIDC automatycznie żąda odpowiednich tokenów przy użyciu kodu zwróconego z punktu końcowego autoryzacji.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Uwaga

  W konfiguracji rejestracji aplikacji dla niejawnych przyznawania i przepływów hybrydowych w Entra lub witrynie Azure Portal nie zaznaczaj żadnego z pól wyboru w punkcie końcowym autoryzacji, aby zwrócić tokeny dostępu lub tokeny ID.

• MapInboundClaims i konfiguracja NameClaimType i RoleClaimType: Wiele serwerów OIDC używa "name" i "role" zamiast domyślnych ustawień SOAP/WS-Fed w ClaimTypes. Gdy MapInboundClaims jest ustawiona wartość false, program obsługi nie wykonuje mapowań roszczeń, a nazwy roszczeń pochodzące z JWT są używane bezpośrednio przez aplikację. W poniższym przykładzie typ oświadczenia roli jest ustawiany na "roles", który jest odpowiedni dla identyfikatora Entra firmy Microsoft (ME-ID). Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dostawcy tożsamości.

  Uwaga

  MapInboundClaims musi być ustawione na false dla większości dostawców OIDC, co uniemożliwia zmianę nazw oświadczeń.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Konfiguracja ścieżki: Ścieżki muszą być zgodne z identyfikatorem URI przekierowania (ścieżką powrotu logowania) oraz ścieżką przekierowania po wylogowaniu (ścieżką powrotu po wylogowaniu), które zostały skonfigurowane podczas rejestrowania aplikacji u dostawcy OIDC. W portalu Azure ścieżki są konfigurowane w panelu Uwierzytelnianie rejestracji aplikacji. Zarówno ścieżki logowania, jak i wylogowania muszą być zarejestrowane jako URI przekierowania. Wartości domyślne to /signin-oidc i /signout-callback-oidc.

  • CallbackPath: ścieżka żądania w ścieżce podstawowej aplikacji, w której jest zwracany agent użytkownika.

    Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost:{PORT}/signin-oidc

    Uwaga

    Port nie jest wymagany dla localhost adresów w przypadku korzystania z identyfikatora Entra firmy Microsoft. Większość innych dostawców OIDC wymaga poprawnego portu.

  • SignedOutCallbackPath (klucz konfiguracji: "SignedOutCallbackPath"): ścieżka żądania w obrębie ścieżki podstawowej aplikacji, przechwycona przez moduł obsługi OIDC, gdzie agent użytkownika jest najpierw zwracany po wylogowaniu się z dostawcy tożsamości. Przykładowa aplikacja nie ustawia wartości dla ścieżki, ponieważ jest używana domyślna wartość "/signout-callback-oidc". Po przechwyceniu żądania, handler OIDC przekierowuje do SignedOutRedirectUri lub RedirectUri, jeśli określono.

    Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost:{PORT}/signout-callback-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw ścieżkę w konfiguracji platformy webowej we wpisach URI przekierowania w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu. Jeśli nie dodasz identyfikatora URI ścieżki wywołania zwrotnego po wylogowaniu do rejestracji aplikacji w Entra, Entra odmawia przekierowania użytkownika z powrotem do aplikacji i prosi jedynie o zamknięcie okna przeglądarki.

  • RemoteSignOutPath: Żądania odebrane na tej ścieżce powodują, że program obsługi wywołuje wylogowywanie przy użyciu schematu wylogowywania.

    W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost/signout-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw adres URL wylogowywania na kanale frontowym w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Przykłady (wartości domyślne):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Platforma Microsoft Azure tylko w przypadku "wspólnego" punktu końcowego): TokenValidationParameters.IssuerValidatorwielu dostawców OIDC współpracuje z domyślnym modułem sprawdzania poprawności wystawcy, ale musimy uwzględnić wystawcę sparametryzowanego przy użyciu identyfikatora dzierżawy ({TENANT ID}) zwróconego przez https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Aby uzyskać więcej informacji, zobacz SecurityTokenInvalidIssuerException z OpenID Connect i punktem końcowym Azure AD "common" (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Tylko w przypadku aplikacji korzystających z identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C z "wspólnym" punktem końcowym:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Przykładowy kod aplikacji

Sprawdź przykładową aplikację pod kątem następujących funkcji:

• Automatyczne odświeżanie tokena bez interakcji przy pomocy niestandardowego cookie odświeżacza (CookieOidcRefresher.cs).
• Składnik Weather używa atrybutu [Authorize] o nazwie, aby zapobiec nieautoryzowanemu dostępowi. Aby uzyskać więcej informacji na temat wymagania autoryzacji w aplikacji za pośrednictwem zasad autoryzacji i pominięcia autoryzacji w przypadku pewnego podzbioru publicznych punktów końcowych, zobacz wskazówki Razor Pages OIDC. Aby uzyskać więcej informacji na temat zabezpieczania danych pogodowych przez tę aplikację, zobacz Zabezpiecz dane w Blazor Web Apps za pomocą interaktywnego automatycznego renderowania.

W tej wersji artykułu opisano implementację OIDC ze wzorcem Backend for Frontend (BFF). Zmień selektor wersji artykułu na wzorzec inny niż BFF (Interaktywne Auto) (Automatyczne renderowanie interaktywne) lub wzorzec inny niż BFF (Interaktywny Serwer) (Interaktywne renderowanie serwerowe), jeśli specyfikacja aplikacji nie wymaga przyjęcia wzorca BFF.

Opisano następującą specyfikację:

• Funkcja Blazor Web App używa trybu automatycznego renderowania z globalną interakcyjnością.
• Niestandardowe usługi dostawcy stanu uwierzytelniania są używane przez serwer i aplikacje klienckie do przechwytywania stanu uwierzytelniania użytkownika i przepływu go między serwerem a klientem.
• Ta aplikacja jest punktem wyjścia dla dowolnego przepływu uwierzytelniania OIDC. OIDC jest konfigurowany ręcznie w aplikacji i nie polega na Microsoft Entra ID ani na pakietach Microsoft Identity Web, a przykładowa aplikacja nie wymaga hostingu na Microsoft Azure. Jednak przykładowa aplikacja może być używana z aplikacją Entra, Microsoft Identity Web i hostowaną na platformie Azure.
• Automatyczne odświeżanie tokenu nieinterakcyjnego.
• Wzorzec Backend for Frontend (BFF) jest przyjęty przy użyciu .NET Aspire do odnajdywania usług i YARP do proxy'owania żądań do punktu końcowego prognozy pogody w aplikacji backend.
  • Zaplecze internetowe API używa uwierzytelniania jako posiadacz JWT do weryfikacji tokenów JWT zapisanych przez Blazor Web App podczas logowania cookie.
  • Aspire ulepsza doświadczenia związane z tworzeniem natywnych aplikacji w chmurze na platformie .NET. Zapewnia spójny, opiniowany zestaw narzędzi i wzorców do tworzenia i uruchamiania aplikacji rozproszonych.
  • YARP (Jeszcze inny zwrotny serwer proxy) to biblioteka używana do tworzenia zwrotnego serwera proxy.

Aby uzyskać więcej informacji na temat .NET Aspire, zobacz General Availability of .NET Aspire: Upraszczanie natywnego tworzenia aplikacji dla platformy chmurowej .NET (maj 2024 r.).

Wymagania wstępne

.NET Aspire program Wymaga programu Visual Studio w wersji 17.10 lub nowszej.

Zobacz również sekcję Prerequisites (Wymagania wstępne) w przewodniku Quickstart : Tworzenie pierwszej aplikacji .NET Aspire.

Przykładowa aplikacja

Przykładowa aplikacja składa się z pięciu projektów:

• .NET Aspire:
  • Aspire.AppHost: służy do zarządzania ogólnymi problemami dotyczącymi aranżacji aplikacji.
  • Aspire.ServiceDefaults: zawiera domyślne .NET Aspire konfiguracje aplikacji, które można rozszerzyć i dostosować zgodnie z potrzebami.
• MinimalApiJwt: internetowy interfejs API zaplecza zawierający przykładowy minimalny punkt końcowy interfejsu API dla danych pogodowych.
• BlazorWebAppOidc: Projekt po stronie serwera programu Blazor Web App.
• BlazorWebAppOidc.Client: projekt kliencki dotyczący Blazor Web App.

Dostęp do przykładu za pośrednictwem najnowszego folderu wersji w repozytorium przykładów Blazor za pomocą następującego linku. Przykład znajduje się w folderze BlazorWebAppOidcBff dla platformy .NET 8 lub nowszej.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Projekty: .NET Aspire

Aby uzyskać więcej informacji na temat korzystania z .NET Aspire oraz szczegóły dotyczące projektów .AppHost i .ServiceDefaults w przykładowej aplikacji, zobacz dokumentację .NET Aspire.

Upewnij się, że zostały spełnione wymagania wstępne dotyczące programu .NET Aspire. Aby uzyskać więcej informacji, zobacz sekcję Wymagania wstępne przewodnika Szybki start: tworzenie pierwszej .NET Aspire aplikacji.

Przykładowa aplikacja konfiguruje tylko niezabezpieczony profil uruchamiania HTTP (http) do użycia podczas testowania programistycznego. Aby uzyskać więcej informacji, w tym przykład niezabezpieczonych i bezpiecznych profilów ustawień uruchamiania, zobacz Zezwalanie na niezabezpieczony transport w .NET Aspire (.NET Aspire dokumentacja).

Projekt serwerowy Blazor Web App (BlazorWebAppOidc)

Projekt BlazorWebAppOidc jest projektem po stronie serwera programu Blazor Web App. Projekt używa YARP do pośredniczenia w żądaniach do punktu końcowego prognozy pogody w projekcie interfejsu API w backendzie (MinimalApiJwt) z danymi przechowywanymi w ramach access_token w uwierzytelnianiu cookie.

Konfigurowanie

W tej sekcji wyjaśniono, jak skonfigurować przykładową aplikację.

Uwaga

W przypadku identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C można AddMicrosoftIdentityWebApp używać w witrynie Microsoft Identity Web (Microsoft.Identity.Web pakietu NuGet, dokumentacji interfejsu API), który dodaje zarówno obsługę OIDC, jak i Cookie programy obsługi uwierzytelniania z odpowiednimi wartościami domyślnymi. Przykładowa aplikacja i wskazówki zawarte w tej sekcji nie korzystają z witryny Microsoft Identity Web. Wskazówki pokazują, jak ręcznie skonfigurować procedurę obsługi OIDC dla dowolnego dostawcy OIDC. Aby uzyskać więcej informacji na temat implementowania sieci Web firmy Microsoft Identity , zobacz połączone zasoby.

Ustawienie sekretu klienta

Ostrzeżenie

Nie przechowuj tajnych danych aplikacji, parametrów połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu C#/.NET lub kluczy prywatnych/tokenów w kodzie po stronie klienta, ponieważ jest zawsze niebezpieczny. 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 Bezpieczne utrzymywanie poufnych danych i poświadczeń.

W przypadku lokalnego testowania programistycznego użyj narzędzia Secret Manager do przechowywania tajnego klienta aplikacji serwera w kluczu Authentication:Schemes:MicrosoftOidc:ClientSecret konfiguracji.

Uwaga

Jeśli aplikacja używa Microsoft Entra ID lub Azure AD B2C, utwórz klucz tajny klienta w rejestracji aplikacji w portalu Entra lub Azure (Zarządzaj>Certyfikaty i tajemnice>Nowy klucz tajemny klienta). Użyj Wartości nowego sekretu w poniższych wskazówkach.

Przykładowa aplikacja nie została zainicjowana dla narzędzia Secret Manager. Użyj powłoki poleceń, takiej jak powłoka poleceń programu PowerShell dla deweloperów w programie Visual Studio, aby wykonać następujące polecenie. Przed wykonaniem polecenia zmień katalog na katalog projektu serwera za pomocą polecenia cd. Polecenie ustanawia identyfikator tajemnic użytkownika (<UserSecretsId> w pliku projektu aplikacji serwera):

dotnet user-secrets init

Wykonaj następujące polecenie, aby ustawić klucz tajny klienta. Symbol zastępczy {SECRET} to tajny klucz klienta uzyskany z rejestracji aplikacji.

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Jeśli używasz programu Visual Studio, możesz potwierdzić, że wpis tajny został ustawiony, klikając prawym przyciskiem myszy projekt serwera w Eksplorator rozwiązań i wybierając polecenie Zarządzaj wpisami tajnymi użytkownika.

Konfigurowanie aplikacji

Następująca OpenIdConnectOptions konfiguracja znajduje się w pliku projektu Program podczas wywołania AddOpenIdConnect:

• SignInScheme: Ustawia schemat uwierzytelniania odpowiadający oprogramowaniu pośredniczącemu odpowiedzialnemu za przechowywanie tożsamości użytkownika po pomyślnym uwierzytelnieniu. Procedura obsługi OIDC musi używać schematu logowania, który może utrwalać poświadczenia użytkownika między żądaniami. Poniższy wiersz jest obecny jedynie na potrzeby demonstracji. W przypadku pominięcia DefaultSignInScheme parametr jest używany jako wartość rezerwowa.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Zakresy dla openid i profile (Scope) (opcjonalnie): Zakresy openid i profile są również konfigurowane domyślnie, ponieważ są one wymagane, aby program obsługi OIDC działał, ale może być konieczne ponowne dodanie tych zakresów, jeśli są one uwzględnione w konfiguracji Authentication:Schemes:MicrosoftOidc:Scope. Aby uzyskać ogólne wskazówki dotyczące konfiguracji, zobacz Konfiguracja w ASP.NET Core i Konfiguracja ASP.NET CoreBlazor.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: Określa, czy tokeny dostępu i odświeżania powinny być przechowywane w AuthenticationProperties po pomyślnej autoryzacji. Wartość jest ustawiona na true, aby uwierzytelniać żądania dotyczące danych pogodowych z projektu webowego interfejsu API zaplecza (MinimalApiJwt).

  oidcOptions.SaveTokens = true;
  

• Zakres dla dostępu offline (Scope): offline_access zakres jest wymagany dla tokenu odświeżania.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Zakresy uzyskiwania danych pogodowych z internetowego interfejsu API (Scope): jest to konieczne, aby projekt internetowego interfejsu API zaplecza (MinimalApiJwt) zweryfikował token dostępu za pomocą elementu nośnego JWT.

  oidcOptions.Scope.Add("{APP ID URI}/{API NAME}");
  

  Uwaga

  W przypadku korzystania z identyfikatora Entra firmy Microsoft zakres Weather.Get jest skonfigurowany w portalu Entra lub portalu Azure w Ujawnij interfejs API.

  Przykład:

  • Identyfikator URI aplikacji ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
    • Nazwa katalogu ({DIRECTORY NAME}): contoso
    • Identyfikator aplikacji (klienta) ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444
  • Zakres skonfigurowany dla danych pogodowych z MinimalApiJwt ({API NAME}): Weather.Get

  oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444/Weather.Get");
  

  Przykład dotyczy aplikacji zarejestrowanej u dzierżawcy o typie AAD B2C. Jeśli aplikacja jest zarejestrowana w dzierżawie ME-ID, identyfikator URI aplikacji jest inny, w związku z tym zakres jest inny.

  Przykład:

  • URI identyfikatora aplikacji ({APP ID URI}): api://{CLIENT ID} z identyfikatorem aplikacji ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444
  • Zakres skonfigurowany dla danych pogodowych z MinimalApiJwt ({API NAME}): Weather.Get

  oidcOptions.Scope.Add("api://00001111-aaaa-2222-bbbb-3333cccc4444/Weather.Get");
  

• Authority i ClientId: Ustawia urząd i identyfikator klienta dla wywołań OIDC.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Przykład:

  • Organ ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (używa identyfikatora dzierżawy aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Identyfikator klienta ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Przykład autorytetu typu "common" dla platformy Microsoft Azure:

  Dla aplikacji wielodostępnych należy używać "wspólnego" autorytetu. Możesz również użyć "ogólnego" autorytetu dla aplikacji jednotenantowych, ale konieczne jest zastosowanie niestandardowego IssuerValidator, jak pokazano w dalszej części tej sekcji.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: Konfiguruje procedurę obsługi OIDC tak, aby wykonywała tylko przepływ kodu autoryzacji. Niejawne dotacje i przepływy hybrydowe są niepotrzebne w tym trybie. Procedura obsługi OIDC automatycznie żąda odpowiednich tokenów przy użyciu kodu zwróconego z punktu końcowego autoryzacji.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Uwaga

  W przypadku korzystania z Microsoft Entra ID nie zaznaczaj żadnego pola wyboru, aby punkt końcowy autoryzacji zwracał Access tokens lub ID tokens w konfiguracji rejestracji aplikacji dotyczącej niejawnego uzyskiwania i przepływów hybrydowych.

• MapInboundClaims i konfiguracja NameClaimType i RoleClaimType: Wiele serwerów OIDC używa "name" i "role" zamiast domyślnych ustawień SOAP/WS-Fed w ClaimTypes. Kiedy MapInboundClaims jest ustawiony na false, mechanizm nie wykonuje mapowania roszczeń, a nazwy roszczeń z zestawu JWT są używane bezpośrednio przez aplikację. W poniższym przykładzie typ oświadczenia roli jest ustawiany na "roles", co jest odpowiednie dla Microsoft Entra ID (ME-ID). Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dostawcy tożsamości.

  Uwaga

  MapInboundClaims musi być ustawione na false dla większości dostawców OIDC, co uniemożliwia zmianę nazw oświadczeń.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Konfiguracja ścieżki: Ścieżki muszą być zgodne z identyfikatorem URI przekierowania (ścieżką powrotu logowania) oraz ścieżką przekierowania po wylogowaniu (ścieżką powrotu po wylogowaniu), które zostały skonfigurowane podczas rejestrowania aplikacji u dostawcy OIDC. W portalu Azure ścieżki są konfigurowane w sekcji Uwierzytelnianie w konfiguracji rejestracji aplikacji. Zarówno ścieżki logowania, jak i wylogowania muszą być zarejestrowane jako URI przekierowania. Wartości domyślne to /signin-oidc i /signout-callback-oidc.

  Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

  https://localhost:{PORT}/signin-oidc

  Uwaga

  Port nie jest wymagany dla localhost adresów w przypadku korzystania z identyfikatora Entra firmy Microsoft. Większość innych dostawców OIDC wymaga poprawnego portu.

  • SignedOutCallbackPath (klucz konfiguracji: "SignedOutCallbackPath"): ścieżka żądania w ścieżce podstawowej aplikacji przechwycona przez program obsługi OIDC, gdzie agent użytkownika jest najpierw zwracany po wylogowaniu się z dostawcy tożsamości. Przykładowa aplikacja nie ustawia wartości dla ścieżki, ponieważ jest używana domyślna wartość "/signout-callback-oidc". Po przechwyceniu żądania, handler OIDC przekierowuje do SignedOutRedirectUri lub RedirectUri, jeśli określono.

    Skonfiguruj ścieżkę wywołania zwrotnego dla wylogowania w rejestracji dostawcy OIDC aplikacji. W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost:{PORT}/signout-callback-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw ścieżkę w konfiguracji platformy webowej we wpisach URI przekierowania w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu. Jeśli nie dodasz identyfikatora URI ścieżki wywołania zwrotnego po wylogowaniu do rejestracji aplikacji w Entra, Entra odmawia przekierowania użytkownika z powrotem do aplikacji i prosi jedynie o zamknięcie okna przeglądarki.

  • RemoteSignOutPath: Żądania odebrane na tej ścieżce powodują, że program obsługi wywołuje wylogowywanie przy użyciu schematu wylogowywania.

    W poniższym przykładzie symbol zastępczy {PORT} jest portem aplikacji:

    https://localhost/signout-oidc

    Uwaga

    Podczas korzystania z Microsoft Entra ID, ustaw adres URL wylogowywania na kanale frontowym w portalu Entra lub Azure. Port nie jest wymagany dla adresów localhost w przypadku korzystania z usługi Entra. Większość innych dostawców OIDC wymaga poprawnego portu.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Przykłady (wartości domyślne):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Platforma Microsoft Azure tylko w przypadku "wspólnego" punktu końcowego): TokenValidationParameters.IssuerValidatorwielu dostawców OIDC współpracuje z domyślnym modułem sprawdzania poprawności wystawcy, ale musimy uwzględnić wystawcę sparametryzowanego przy użyciu identyfikatora dzierżawy ({TENANT ID}) zwróconego przez https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Aby uzyskać więcej informacji, zobacz SecurityTokenInvalidIssuerException z OpenID Connect i punktem końcowym Azure AD "common" (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Tylko w przypadku aplikacji korzystających z identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C z "wspólnym" punktem końcowym:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Przykładowy kod aplikacji

Sprawdź przykładową aplikację pod kątem następujących funkcji:

• Automatyczne odświeżanie tokena bez interakcji przy pomocy niestandardowego cookie odświeżacza (CookieOidcRefresher.cs).
• Projekt serwera wywołuje AddAuthenticationStateSerialization, aby dodać dostawcę stanu uwierzytelniania po stronie serwera, który używa PersistentComponentState do przesyłania stanu uwierzytelniania do klienta. Klient wywołuje AddAuthenticationStateDeserialization w celu deserializacji i użycia stanu uwierzytelniania przekazanego przez serwer. Stan uwierzytelniania jest stały dla okresu istnienia aplikacji WebAssembly.
• Żądania do Blazor Web App są przekierowywane do projektu API backendu (MinimalApiJwt). MapForwarder w pliku Program dodaje bezpośrednie przekazywanie żądań HTTP pasujących do określonego wzorca do określonego miejsca docelowego, z użyciem domyślnej konfiguracji dla żądania wychodzącego, dostosowanych przekształceń oraz domyślnego klienta HTTP.
  • Podczas renderowania składnika Weather na serwerze składnik używa klasy ServerWeatherForecaster jako pośrednika na żądanie danych pogodowych przy użyciu tokenu dostępu użytkownika. IHttpContextAccessor.HttpContext określa, czy HttpContext jest dostępny do użycia przez metodę GetWeatherForecastAsync. Aby uzyskać więcej informacji, zobacz ASP.NET Core Razor components.
  • Gdy składnik jest renderowany na kliencie, używa implementacji usługi ClientWeatherForecaster, która korzysta z wstępnie skonfigurowanego HttpClient (w pliku projektu klienta Program), aby nawiązać połączenie z internetowym interfejsem API w projekcie serwera. Minimalny punkt końcowy interfejsu API (/weather-forecast) zdefiniowany w pliku projektu Program serwera przekształca żądanie przy użyciu tokenu dostępu użytkownika w celu uzyskania danych pogodowych.

Aby uzyskać więcej informacji na temat wywołań interfejsu API sieci Web przy użyciu abstrakcji usługi w Blazor Web App, zobacz Wywołaj interfejs API sieci Web z aplikacji ASP.NET Core Blazor.

Projekt po stronie Blazor Web App klienta (BlazorWebAppOidc.Client)

Projekt BlazorWebAppOidc.Client jest projektem po stronie klienta programu Blazor Web App.

Klient wywołuje AddAuthenticationStateDeserialization w celu deserializacji i użycia stanu uwierzytelniania przekazanego przez serwer. Stan uwierzytelniania jest stały dla okresu istnienia aplikacji WebAssembly.

Jeśli użytkownik musi się zalogować lub wylogować, wymagane jest ponowne załadowanie pełnej strony.

Przykładowa aplikacja udostępnia tylko nazwę użytkownika i adres e-mail do celów wyświetlania. Nie obejmuje tokenów uwierzytelniających się na serwerze podczas podejmowania kolejnych żądań, które działają oddzielnie przy użyciu elementu cookie uwzględnionego w HttpClient żądaniach do serwera.

Projekt internetowego interfejsu API zaplecza (MinimalApiJwt)

Projekt MinimalApiJwt jest backendowym API dla wielu projektów frontendowych. Projekt konfiguruje minimalny punkt końcowy interfejsu API dla danych pogodowych. Żądania z Blazor Web App projektu po stronie serwera (BlazorWebAppOidc) są kierowane do MinimalApiJwt projektu.

Plik MinimalApiJwt.http może służyć do testowania żądania danych pogodowych. Należy pamiętać, że MinimalApiJwt projekt musi być uruchomiony, aby przetestować punkt końcowy, a punkt końcowy jest zakodowany w pliku. Aby uzyskać więcej informacji, zobacz Use .http files in Visual Studio 2022 (Używanie plików HTTP w programie Visual Studio 2022).

Konfigurowanie

Skonfiguruj projekt w JwtBearerOptions wywołaniu AddJwtBearer w pliku projektu Program :

• Audience: ustawia grupę odbiorców dla dowolnego odebranego tokenu OIDC.

  jwtOptions.Audience = "{APP ID URI}";
  

  Uwaga

  W przypadku korzystania z identyfikatora Entra firmy Microsoft dopasuj wartość tylko do ścieżki identyfikatora URI identyfikatora aplikacji skonfigurowanego podczas dodawania zakresu Weather.Get w obszarze Uwidaczniaj interfejsu API w witrynie Entra lub Witrynie Azure Portal.

  Przykład:

  Identyfikator URI aplikacji ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}

  • Nazwa katalogu ({DIRECTORY NAME}): contoso
  • Identyfikator aplikacji (klienta) ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Przykład dotyczy aplikacji zarejestrowanej u dzierżawcy o typie AAD B2C. Jeśli aplikacja jest zarejestrowana w dzierżawie ME-ID, identyfikator URI aplikacji jest inny, a co za tym idzie, odbiorca jest inny.

  Przykład:

  URI identyfikatora aplikacji ({APP ID URI}): api://{CLIENT ID} z identyfikatorem aplikacji ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "api://00001111-aaaa-2222-bbbb-3333cccc4444";
  

• Authority: Konfiguruje autoryzację do wykonywania wywołań OIDC. Dopasuj wartość do autorytetu skonfigurowanego dla obsługi OIDC w BlazorWebAppOidc/Program.cs:

  jwtOptions.Authority = "{AUTHORITY}";
  

  Przykład:

  Organ ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (używa identyfikatora dzierżawy aaaabbbb-0000-cccc-1111-dddd2222eeee)

  jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  

  Przykład dotyczy aplikacji zarejestrowanej u dzierżawcy o typie AAD B2C. Jeśli aplikacja jest zarejestrowana w dzierżawie ME-ID, autorytet powinien być zgodny z wydawcą (iss) tokenu JWT zwróconego przez dostawcę tożsamości.

  jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
  

Minimalny interfejs API dla danych pogodowych

Bezpieczny punkt końcowy danych prognozy pogody w pliku Program projektu:

app.MapGet("/weather-forecast", () =>
{
    var forecast = 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();
    return forecast;
}).RequireAuthorization();

Metoda RequireAuthorization rozszerzenia wymaga autoryzacji dla definicji trasy. W przypadku wszystkich kontrolerów dodanych do projektu dodaj [Authorize] atrybut do kontrolera lub akcji.

Przekieruj do strony głównej po wylogowaniu

Składnik LogInOrOut (Layout/LogInOrOut.razor) ustawia ukryte pole dla zwracanego adresu URL (ReturnUrl) na bieżący adres URL (currentURL). Gdy użytkownik wyloguje się z aplikacji, dostawca tożsamości zwraca użytkownika do strony, z której się wylogował. Jeśli użytkownik wyloguje się z bezpiecznej strony, zostanie zwrócony do tej samej bezpiecznej strony i odesłany przez proces uwierzytelniania. Ten przepływ uwierzytelniania jest rozsądny, gdy użytkownicy muszą regularnie zmieniać konta.

Alternatywnie użyj następującego składnika LogInOrOut, który nie dostarcza adresu URL zwrotnego podczas wylogowywania.

Layout/LogInOrOut.razor:

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout
                </button>
            </form>
        </Authorized>
        <NotAuthorized>
            <a class="nav-link" href="authentication/login">
                <span class="bi bi-person-badge-nav-menu" aria-hidden="true"></span> 
                Login
            </a>
        </NotAuthorized>
    </AuthorizeView>
</div>

Odświeżenie tokenu

Implementacja niestandardowego modułu odświeżania cookie (CookieOidcRefresher.cs) automatycznie aktualizuje roszczenia użytkownika, gdy wygasną. Bieżąca implementacja oczekuje otrzymania tokenu ID w zamian za token odświeżający z punktu końcowego tokenu. Oświadczenia w tym tokenie identyfikatora są następnie używane do zastępowania oświadczeń użytkownika.

Przykładowa implementacja nie zawiera kodu do żądania oświadczeń z punktu końcowego UserInfo podczas odświeżania tokenu. Aby uzyskać więcej informacji, zobacz BlazorWebAppOidc AddOpenIdConnect with GetClaimsFromUserInfoEndpoint = true doesn't propogate role claims to client (dotnet/aspnetcore #58826).

Uwaga

Niektórzy dostawcy tożsamości zwracają token dostępu tylko wtedy, gdy używany jest token odświeżania. CookieOidcRefresher można zaktualizować za pomocą dodatkowej logiki, aby można było dalej korzystać z wcześniejszego zestawu roszczeń przechowywanych w autoryzacji cookie lub użyć tokenu dostępu do żądania roszczeń z punktu końcowego UserInfo.

Kryptograficzny licznik jednorazowy

Nonce jest wartością ciągu, która kojarzy sesję klienta z tokenem identyfikatora w celu złagodzenia ataków powtarzania.

Jeśli podczas opracowywania i testowania uwierzytelniania wystąpi błąd nonca, użyj nowej sesji przeglądarki InPrivate/incognito dla każdego przebiegu testowego, niezależnie od tego, jak mała zmiana została wprowadzona w aplikacji lub na koncie użytkownika testowego, ponieważ nieaktualne dane cookie mogą prowadzić do błędu nonca. Aby uzyskać więcej informacji, zobacz sekcję Pliki cookie i dane witryny.

Nonce nie jest wymagany ani używany, gdy token odświeżania jest wymieniany na nowy token dostępu. W przykładowej aplikacji CookieOidcRefresher (CookieOidcRefresher.cs) celowo ustawia OpenIdConnectProtocolValidator.RequireNonce na false.

Role dla aplikacji, które nie zostały zarejestrowane w usłudze Microsoft Entra (ME-ID)

Ta sekcja dotyczy aplikacji, które nie używają Microsoft Entra ID (ME-ID) jako dostawcy tożsamości. W przypadku aplikacji zarejestrowanych przy użyciu identyfikatora ME zobacz sekcję Role aplikacji dla aplikacji zarejestrowanych w usłudze Microsoft Entra (ME-ID).

Skonfiguruj typ oświadczenia roli (TokenValidationParameters.RoleClaimType) w elemencie OpenIdConnectOptions:Program.cs

oidcOptions.TokenValidationParameters.RoleClaimType = "{ROLE CLAIM TYPE}";

W przypadku wielu dostawców tożsamości OIDC typ oświadczenia roli jest role. Sprawdź dokumentację dostawcy tożsamości, aby znaleźć poprawną wartość.

Zastąp klasę UserInfo w projekcie BlazorWebAppOidc.Client następującą klasą.

UserInfo.cs:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;

namespace BlazorWebAppOidc.Client;

// Add properties to this class and update the server and client 
// AuthenticationStateProviders to expose more information about 
// the authenticated user to the client.
public sealed class UserInfo
{
    public required string UserId { get; init; }
    public required string Name { get; init; }
    public required string[] Roles { get; init; }

    public const string UserIdClaimType = "sub";
    public const string NameClaimType = "name";
    private const string RoleClaimType = "role";

    public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
        new()
        {
            UserId = GetRequiredClaim(principal, UserIdClaimType),
            Name = GetRequiredClaim(principal, NameClaimType),
            Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
                .ToArray(),
        };

    public ClaimsPrincipal ToClaimsPrincipal() =>
        new(new ClaimsIdentity(
            Roles.Select(role => new Claim(RoleClaimType, role))
                .Concat([
                    new Claim(UserIdClaimType, UserId),
                    new Claim(NameClaimType, Name),
                ]),
            authenticationType: nameof(UserInfo),
            nameType: NameClaimType,
            roleType: RoleClaimType));

    private static string GetRequiredClaim(ClaimsPrincipal principal,
        string claimType) =>
            principal.FindFirst(claimType)?.Value ??
            throw new InvalidOperationException(
                $"Could not find required '{claimType}' claim.");
}

W tym momencie Razor składniki mogą przyjąć autoryzację opartą na rolach i opartą na zasadach. Role aplikacji pojawiają się w role roszczeniach, jedno roszczenie na rolę.

Role aplikacji dla aplikacji zarejestrowanych w usłudze Microsoft Entra (ME-ID)

Skorzystaj ze wskazówek w tej sekcji, aby zaimplementować role aplikacji, grupy zabezpieczeń ME-ID i wbudowane role administratora ME-ID dla aplikacji przy użyciu identyfikatora Entra (ME-ID) firmy Microsoft.

Podejście opisane w tej sekcji konfiguruje ME-ID w celu wysyłania grup i ról w nagłówku uwierzytelniania cookie. Jeśli użytkownicy są tylko członkami kilku grup zabezpieczeń i ról, poniższe podejście powinno działać w przypadku większości platform hostingu bez wystąpienia problemu, w którym nagłówki są zbyt długie, na przykład w przypadku hostingu usług IIS, który ma domyślny limit długości nagłówka 16 KB (MaxRequestBytes). Jeśli długość nagłówka jest problemem z powodu członkostwa w grupie lub roli, zalecamy, aby nie przestrzegać wskazówek w tej sekcji na rzecz implementacji programu Microsoft Graph w celu uzyskania grup i ról użytkownika z identyfikatora ME-ID oddzielnie, podejście, które nie zawyża rozmiaru uwierzytelniania cookie. Aby uzyskać więcej informacji, zobacz Nieprawidłowe żądanie — zbyt długie żądanie — serwer IIS (dotnet/aspnetcore #57545).

Skonfiguruj typ oświadczenia roli (TokenValidationParameters.RoleClaimType) w OpenIdConnectOptions pliku Program.cs. Ustaw wartość na roles:

oidcOptions.TokenValidationParameters.RoleClaimType = "roles";

Chociaż nie można przypisywać ról do grup bez konta premium ME-ID, możesz przypisać role do użytkowników i odbierać oświadczenia ról dla użytkowników przy użyciu standardowego konta platformy Azure. Wskazówki w tej sekcji nie wymagają konta Premium z identyfikatorem ME.ID.

Podczas pracy z katalogiem domyślnym postępuj zgodnie ze wskazówkami w Dodawanie ról aplikacji do aplikacji i odbieranie ich w tokenie (dokumentacja ME-ID), aby role skonfigurować i przypisać. Jeśli nie pracujesz z katalogiem domyślnym, zmodyfikuj manifest aplikacji w witrynie Azure Portal, aby ręcznie ustanowić role aplikacji we appRoles wpisie pliku manifestu. Aby uzyskać więcej informacji, zobacz Konfigurowanie oświadczenia roli (dokumentacja ME-ID)..

Grupy zabezpieczeń platformy Azure użytkownika pojawiają się w oświadczeniach groups, a wbudowane przypisania ról administratora ME-ID użytkownika pojawiają się w powszechnie znanych identyfikatorach (wids) oświadczeń. Wartości obu typów roszczeń to identyfikatory GUID. Po odebraniu przez aplikację te oświadczenia mogą służyć do ustanawiania autoryzacji roli i zasad w Razor składnikach.

W manifeście aplikacji w portalu Azure ustaw atrybut na . Wartość All powoduje, że identyfikator ME-ID wysyła wszystkie grupy zabezpieczeń/dystrybucji (groups roszczeń) i ról (wids roszczeń) zalogowanego użytkownika. Aby ustawić groupMembershipClaims atrybut:

1. Otwórz rejestrację aplikacji w witrynie Azure Portal.
2. Wybierz Zarządzaj>Manifestem na pasku bocznym.
3. Znajdź groupMembershipClaims atrybut.
4. Ustaw wartość na All ("groupMembershipClaims": "All").
5. Wybierz przycisk zapisywania.

Zastąp klasę UserInfo w projekcie BlazorWebAppOidc.Client następującą klasą.

UserInfo.cs:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;

namespace BlazorWebAppOidc.Client;

// Add properties to this class and update the server and client 
// AuthenticationStateProviders to expose more information about 
// the authenticated user to the client.
public sealed class UserInfo
{
    public required string UserId { get; init; }
    public required string Name { get; init; }
    public required string[] Roles { get; init; }
    public required string[] Groups { get; init; }
    public required string[] Wids { get; init; }

    public const string UserIdClaimType = "sub";
    public const string NameClaimType = "name";
    private const string RoleClaimType = "roles";
    private const string GroupsClaimType = "groups";
    private const string WidsClaimType = "wids";

    public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
        new()
        {
            UserId = GetRequiredClaim(principal, UserIdClaimType),
            Name = GetRequiredClaim(principal, NameClaimType),
            Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
                .ToArray(),
            Groups = principal.FindAll(GroupsClaimType).Select(c => c.Value)
                .ToArray(),
            Wids = principal.FindAll(WidsClaimType).Select(c => c.Value)
                .ToArray(),
        };

    public ClaimsPrincipal ToClaimsPrincipal() =>
        new(new ClaimsIdentity(
            Roles.Select(role => new Claim(RoleClaimType, role))
                .Concat(Groups.Select(role => new Claim(GroupsClaimType, role)))
                .Concat(Wids.Select(role => new Claim(WidsClaimType, role)))
                .Concat([
                    new Claim(UserIdClaimType, UserId),
                    new Claim(NameClaimType, Name),
                ]),
            authenticationType: nameof(UserInfo),
            nameType: NameClaimType,
            roleType: RoleClaimType));

    private static string GetRequiredClaim(ClaimsPrincipal principal,
        string claimType) =>
            principal.FindFirst(claimType)?.Value ??
            throw new InvalidOperationException(
                $"Could not find required '{claimType}' claim.");
}

Na tym etapie Razor składniki mogą przyjąć autoryzację opartą na rolach i opartą na zasadach:

• Role aplikacji pojawiają się w roles roszczeniach, jedno roszczenie na rolę.
• Grupy zabezpieczeń występują w groups oświadczeniach, jedno oświadczenie na grupę. Identyfikatory GUID grupy zabezpieczeń pojawiają się w portalu Azure, gdy tworzysz grupę zabezpieczeń, i są wymienione podczas wybierania Identity>Przegląd>Grupy>Widok.
• Wbudowane role administratora ME-ID pojawiają się w wids oświadczeniach, a każda rola ma własne oświadczenie. Oświadczenie wids z wartością b79fbf4d-3ef9-4689-8143-76b194e85509 jest zawsze wysyłane przez ME-ID dla kont dzierżawcy innych niż gość i nie odnosi się do roli administratora. Identyfikatory GUID ról administratora (identyfikatory szablonów ról) pojawiają się w portalu Azure po wybraniu Ról i administratorów, a następnie kliknięciu wielokropka (…) > dla wymienionej roli. Identyfikatory szablonów ról są również wymienione w wbudowanych rolach Microsoft Entra (dokumentacja Entra).

Rozwiązywanie problemów

Rejestrowanie

Aplikacja serwera jest standardową aplikacją ASP.NET Core. Zobacz wskazówki dotyczące logowania w ASP.NET Core, aby włączyć niższy poziom logowania w aplikacji serwera.

Aby włączyć rejestrowanie debugowania lub śledzenia dla Blazor WebAssembly uwierzytelniania, zapoznaj się z sekcją Rejestrowanie uwierzytelniania po stronie klienta w logach ASP.NET Core Blazor, z selektorem wersji artykułu ustawionym na ASP.NET Core 7.0 lub wyższym.

Typowe błędy

• Błędna konfiguracja aplikacji lub Identity dostawcy (IP)

  Najczęstsze błędy są spowodowane nieprawidłową konfiguracją. Poniżej przedstawiono kilka przykładów:

  • W zależności od wymagań scenariusza brakujący lub niepoprawny autorytet, instancja, identyfikator dzierżawy, domena dzierżawy, identyfikator klienta lub identyfikator URI przekierowania uniemożliwia aplikacji uwierzytelnianie klientów.
  • Nieprawidłowe zakresy żądań uniemożliwiają klientom uzyskiwanie dostępu do punktów końcowych internetowego interfejsu API serwera.
  • Nieprawidłowe lub brakujące uprawnienia interfejsu API serwera uniemożliwiają klientom uzyskiwanie dostępu do punktów końcowych internetowego interfejsu API serwera.
  • Uruchamianie aplikacji na innym porcie niż skonfigurowano w URI przekierowania rejestracji aplikacji IP. Należy pamiętać, że port nie jest wymagany dla identyfikacji Microsoft Entra ani aplikacji działającej localhost na adresie testowym programistycznym, ale konfiguracja portu aplikacji i port, na którym działa aplikacja, musi być zgodna z adresami innymi niż localhost.

  W tym artykule przedstawiono przykłady poprawnej konfiguracji. Dokładnie sprawdź konfigurację wyszukując błędną konfigurację aplikacji i adresu IP.

  Jeśli konfiguracja jest poprawna:

  • Analizowanie dzienników aplikacji.

  • Sprawdź ruch sieciowy między aplikacją kliencka a adresem IP lub aplikacją serwera przy użyciu narzędzi deweloperskich przeglądarki. Często dokładny komunikat o błędzie lub komunikat zawierający wskazówki dotyczące przyczyn problemu jest zwracany do klienta przez adres IP lub aplikację serwera po wykonaniu żądania. Wskazówki dotyczące narzędzi programistycznych znajdują się w następujących artykułach.

    • Google Chrome (dokumentacja Google)
    • Microsoft Edge
    • Mozilla Firefox (dokumentacja Mozilla)

  Zespół dokumentacji odpowiada na opinie dotyczące dokumentów i zgłoszone usterki w artykułach (otwórz zgłoszenie w sekcji opinii z tej strony), ale nie może zapewnić wsparcia dla produktów. Dostępnych jest kilka publicznych forów pomocy technicznej, które ułatwiają rozwiązywanie problemów z aplikacją. Zalecamy:

  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

  Poprzednie fora nie należą do firmy Microsoft ani nie są kontrolowane przez firmę Microsoft.

  W przypadku raportów usterek ramowych niezwiązanych z zabezpieczeniami, niewrażliwych i niepoufnych, zgłoś problem do jednostki produktowej ASP.NET Core. Nie otwieraj problemu z jednostką produktu, dopóki nie zbadasz dokładnie przyczyny problemu i nie możesz go rozwiązać samodzielnie i z pomocą społeczności na publicznym forum pomocy technicznej. Jednostka produktu nie może rozwiązywać problemów z poszczególnymi aplikacjami, które są uszkodzone z powodu prostej błędnej konfiguracji lub przypadków użycia obejmujących usługi innych firm. Jeśli raport jest poufny lub poufny lub opisuje potencjalną lukę w zabezpieczeniach produktu, którą mogą wykorzystać cyberataki, zobacz Raportowanie problemów z zabezpieczeniami i usterek (dotnet/aspnetcorerepozytorium GitHub).

• Nieautoryzowany klient dla ME-ID

  info: Autoryzacja Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] nie powiodła się. Te wymagania nie zostały spełnione: DenyAnonymousAuthorizationRequirement: Wymaga uwierzytelnionego użytkownika.

  Błąd wywołania zwrotnego logowania z ME-ID:

  • Błąd: unauthorized_client
  • Opis: AADB2C90058: The provided application is not configured to allow public clients.

  Aby naprawić ten błąd:

  1. W witrynie Azure Portal uzyskaj dostęp do manifestu aplikacji.
  2. allowPublicClient Ustaw atrybut na null lub true.

Pliki cookie i dane witryn

Pliki cookie i dane witryn mogą być utrwalane w aktualizacjach aplikacji i zakłócać testowanie i rozwiązywanie problemów. Wyczyść następujące informacje podczas wprowadzania zmian w kodzie aplikacji, zmiany konta użytkownika w dostawcy lub zmiany konfiguracji aplikacji dostawcy:

• Pliki cookie logowania użytkownika
• Pliki cookie aplikacji
• Buforowane i przechowywane dane lokacji

Jedną z metod zapobiegania zakłócaniu testowania i rozwiązywania problemów przez utrzymujące się pliki cookie i dane witryny jest:

• Konfigurowanie przeglądarki
  • Użyj przeglądarki do testowania, którą można skonfigurować, aby usuwać wszystkie cookie i dane witryny za każdym razem, gdy zamykasz przeglądarkę.
  • Upewnij się, że przeglądarka jest zamknięta ręcznie lub przez środowisko IDE w celu zmiany konfiguracji aplikacji, użytkownika testowego lub dostawcy.
• Użyj polecenia niestandardowego, aby otworzyć przeglądarkę w trybie InPrivate lub Incognito w programie Visual Studio:
  • Otwórz okno dialogowe Przeglądaj za pomocą z poziomu przycisku Uruchom w programie Visual Studio.
  • Kliknij przycisk Dodaj.
  • Podaj ścieżkę do przeglądarki w polu Program . Następujące ścieżki wykonywalne to typowe lokalizacje instalacji systemu Windows 10. Jeśli przeglądarka jest zainstalowana w innej lokalizacji lub nie używasz systemu Windows 10, podaj ścieżkę do pliku wykonywalnego przeglądarki.
    • Microsoft Edge: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • W polu Argumenty podaj opcję wiersza polecenia używaną przez przeglądarkę do otwierania w trybie InPrivate lub Incognito. Niektóre przeglądarki wymagają adresu URL aplikacji.
    • Microsoft Edge: użyj -inprivate.
    • Google Chrome: użyj --incognito --new-window {URL}, gdzie {URL} to adres URL do otwarcia (na przykład https://localhost:5001).
    • Mozilla Firefox: Użyj -private -url {URL}, gdzie {URL} to adres URL do otwarcia (na przykład https://localhost:5001).
  • Podaj nazwę w polu Przyjazna nazwa . Na przykład Firefox Auth Testing.
  • Wybierz przycisk OK.
  • Aby uniknąć konieczności wybierania profilu przeglądarki dla każdej iteracji testowania za pomocą aplikacji, ustaw profil jako domyślny przy użyciu przycisku Ustaw jako domyślny .
  • Upewnij się, że przeglądarka jest zamknięta przez środowisko IDE w celu zmiany konfiguracji aplikacji, użytkownika testowego lub dostawcy.

Uaktualnienia aplikacji

Działająca aplikacja może zakończyć się niepowodzeniem natychmiast po uaktualnieniu zestawu .NET Core SDK na komputerze deweloperskim lub zmianie wersji pakietów w aplikacji. W niektórych przypadkach niespójne pakiety mogą spowodować przerwanie aplikacji podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, wykonując następujące instrukcje:

1. Wyczyść pamięć podręczną pakietów NuGet systemu lokalnego, wykonując polecenie dotnet nuget locals all --clear w powłoce poleceń.
2. Usuń foldery bin i obj projektu.
3. Przywróć i odbuduj projekt.
4. Usuń wszystkie pliki w folderze wdrażania na serwerze przed ponownym wdrożeniem aplikacji.

Uwaga

Korzystanie z wersji pakietów niezgodnych z platformą docelową aplikacji nie jest obsługiwane. Aby uzyskać informacje o pakiecie, skorzystaj z Galerii NuGet.

Uruchamianie aplikacji serwera

Podczas testowania i rozwiązywania problemów Blazor Web Appupewnij się, że aplikacja jest uruchamiana z projektu serwera.

Sprawdzanie użytkownika

Poniższy UserClaims składnik może być używany bezpośrednio w aplikacjach lub służyć jako podstawa dalszego dostosowywania.

UserClaims.razor:

@page "/user-claims"
@using System.Security.Claims
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

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

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

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

    protected override async Task OnInitializedAsync()
    {
        if (AuthState == null)
        {
            return;
        }

        var authState = await AuthState;
        claims = authState.User.Claims;
    }
}

Dodatkowe zasoby

• AzureAD/microsoft-identity-web Repozytorium GitHub: przydatne wskazówki dotyczące implementowania usługi Microsoft Identity Web for Microsoft Entra ID i Azure Active Directory B2C dla aplikacji ASP.NET Core, w tym linki do przykładowych aplikacji i powiązanej dokumentacji platformy Azure. Obecnie Blazor Web App nie są explicite wspomniane w dokumentacji platformy Azure, ale konfiguracja Blazor Web App dla identyfikatora ME-ID i hostingu platformy Azure jest taka sama jak w przypadku dowolnej aplikacji webowej ASP.NET Core.
• AuthenticationStateProvider usługa
• Zarządzanie stanem uwierzytelniania w Blazor Web Apps
• Odśwież token podczas żądania HTTP na Blazor Serwerze Interaktywnym za pomocą identyfikatora OIDC (dotnet/aspnetcore #55213)
• Zabezpiecz dane w Blazor Web Appza pomocą interaktywnego automatycznego renderowania