Share via

Zabezpečení webové aplikace ASP.NET Core Blazor pomocí OpenID Připojení (OIDC)

  • Článek

Tento článek popisuje, jak zabezpečit Blazor webovou aplikaci pomocí OpenID Připojení (OIDC) pomocí ukázkové aplikace vdotnet/blazor-samplesúložišti GitHub (.NET 8 nebo novější) (jak stáhnout).

Tato verze článku popisuje implementaci OIDC bez přijetí modelu back-endu pro front-end (BFF). Model BFF je užitečný pro provádění ověřených požadavků na externí služby. Pokud specifikace aplikace volá přijetí vzoru BFF, změňte selektor verze článku na OIDC s modelem BFF .

Probírá se následující specifikace:

  • Blazor Webová aplikace používá režim automatického vykreslování s globální interaktivitou.
  • Vlastní služby zprostředkovatele stavu ověřování používají serverové a klientské aplikace k zachycení stavu ověřování uživatele a jeho toku mezi serverem a klientem.
  • Tato aplikace je výchozím bodem pro jakýkoli tok ověřování OIDC. OIDC je v aplikaci nakonfigurovaný ručně a nespoléhá na microsoft Entra ID ani webové balíčky MicrosoftuIdentity, ani ukázková aplikace nevyžaduje hostování Microsoft Azure. Ukázková aplikace se ale může používat s entra, webem Microsoftu Identity a hostovanými v Azure.
  • Automatická neinteraktivní aktualizace tokenu
  • Bezpečně volá (webové) rozhraní API v serverovém projektu pro data.

Ukázková aplikace

Ukázková aplikace se skládá ze dvou projektů:

  • BlazorWebAppOidc: Projekt Blazor na straně serveru webové aplikace, který obsahuje příklad koncového bodu rozhraní API pro data o počasí.
  • BlazorWebAppOidc.Client: Projekt Blazor na straně klienta webové aplikace.

Pomocí následujícího odkazu přejděte k ukázkovým aplikacím prostřednictvím složky nejnovější verze z kořenového adresáře úložiště. Projekty jsou ve BlazorWebAppOidc složce pro .NET 8 nebo novější.

Zobrazení nebo stažení ukázkového kódu (postup stažení)

Projekt webové aplikace na straně Blazor serveru (BlazorWebAppOidc)

Projekt BlazorWebAppOidc je projekt Blazor na straně serveru webové aplikace.

Soubor BlazorWebAppOidc.http lze použít k testování žádosti o data o počasí. Mějte na paměti, že projekt BlazorWebAppOidc musí být spuštěn pro otestování koncového bodu a koncový bod je pevně zakódovaný do souboru. Další informace naleznete v tématu Použití souborů .http v sadě Visual Studio 2022.

Poznámka:

Serverový projekt používá IHttpContextAccessor/HttpContext, ale nikdy pro interaktivně vykreslené komponenty. Další informace najdete v tématu Pokyny ke zmírnění hrozeb pro vykreslování na straně serveru ASP.NET CoreBlazor.

Konfigurace

Tato část vysvětluje, jak nakonfigurovat ukázkovou aplikaci.

Poznámka:

Pro Microsoft Entra ID a Azure AD B2C můžete použít z webu Microsoftu Identity (Microsoft.Identity.Webbalíček NuGet, dokumentace k rozhraní API), který přidá obslužné rutiny OIDC i Cookie ověřování s příslušnými výchozími nastaveními.AddMicrosoftIdentityWebApp Ukázková aplikace a pokyny v této části nepoužívají web Microsoftu Identity . Pokyny ukazují, jak RUČNĚ nakonfigurovat obslužnou rutinu OIDC pro libovolného zprostředkovatele OIDC. Další informace o implementaci webu společnosti Microsoft Identity naleznete v odkazovaných prostředcích.

Následující OpenIdConnectOptions konfigurace se nachází v souboru projektu Program při volání AddOpenIdConnect:

  • SignInScheme: Nastaví schéma ověřování odpovídající middlewaru zodpovědnému za zachování identity uživatele po úspěšném ověření. Obslužná rutina OIDC musí používat schéma přihlašování, které dokáže uchovávat přihlašovací údaje uživatelů napříč požadavky. Následující řádek je k dispozici pouze pro demonstrační účely. Pokud tuto hodnotu vynecháte, DefaultSignInScheme použije se jako záložní hodnota.

    oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;

  • Obory pro openid a profile () (Scopevolitelné): Obory openid a profile obory jsou také ve výchozím nastavení nakonfigurované, protože jsou vyžadovány pro fungování obslužné rutiny OIDC, ale pokud jsou obory zahrnuté v Authentication:Schemes:MicrosoftOidc:Scope konfiguraci, může být potřeba je znovu přidat. Obecné pokyny ke konfiguraci najdete v tématu Konfigurace v konfiguraci ASP.NET Core a ASP.NET CoreBlazor.

    oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);

  • SaveTokens: Definuje, jestli mají být po úspěšné autorizaci uloženy AuthenticationProperties přístupové a obnovovací tokeny. Tato vlastnost je ve výchozím nastavení nastavena tak false , aby se zmenšila velikost konečného ověřování cookie.

    oidcOptions.SaveTokens = false;

  • Rozsah pro offline přístup (Scope): Obor offline_access je vyžadován pro obnovovací token.

    oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

  • Authority a ClientId: Nastaví autoritu a ID klienta pro volání OIDC.

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

    Příklad:

    • Autorita (): https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ ({AUTHORITY}používá ID a3942615-d115-4eb7-bc84-9974abcf5064tenanta)
    • ID klienta ({CLIENT ID}): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
    oidcOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";
oidcOptions.ClientId = "4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";

    Příklad pro "běžnou" autoritu Microsoft Azure:

    Pro aplikace s více tenanty by se měla používat "společná" autorita. Můžete také použít "společnou" autoritu pro aplikace s jedním tenantem, ale vyžaduje se vlastní IssuerValidator , jak je znázorněno dále v této části.

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

  • ClientSecret: Tajný klíč klienta OIDC.

    Následující příklad je určen pouze pro účely testování a demonstrací. Neukládejte tajný kód klienta do sestavení aplikace ani tajný kód nekontrolujte do správy zdrojového kódu. Uložte tajný klíč klienta do tajných kódů uživatelů, azure Key Vaultu nebo proměnné prostředí.

    Konfigurace schématu ověřování se automaticky čte z builder.Configuration["Authentication:Schemes:{SCHEME NAME}:{PropertyName}"], kde {SCHEME NAME} zástupný symbol je schéma, což je MicrosoftOidc ve výchozím nastavení. Vzhledem k tomu, že konfigurace je předkonfigurovaná, je možné tajný klíč klienta automaticky číst prostřednictvím konfiguračního Authentication:Schemes:MicrosoftOidc:ClientSecret klíče. Na serveru pomocí proměnných prostředí pojmenujte proměnnou Authentication__Schemes__MicrosoftOidc__ClientSecretprostředí:

    set Authentication__Schemes__MicrosoftOidc__ClientSecret={CLIENT SECRET}

    Pouze pro ukázku ClientSecret a testování lze nastavit přímo. Nenastavujte hodnotu přímo pro nasazené produkční aplikace. V případě mírně vylepšeného zabezpečení podmíněně zkompilujte řádek se DEBUG symbolem:

    #if DEBUG
oidcOptions.ClientSecret = "{CLIENT SECRET}";
#endif

    Příklad:

    Tajný klíč klienta ({CLIENT SECRET}): 463471c8c4...f90d674bc9 (zkrácený pro zobrazení)

    #if DEBUG
oidcOptions.ClientSecret = "463471c8c4...137f90d674bc9";
#endif

  • ResponseType: Nakonfiguruje obslužnou rutinu OIDC tak, aby prováděla pouze tok autorizačního kódu. Implicitní granty a hybridní toky nejsou v tomto režimu zbytečné.

    V konfiguraci implicitního udělení a registrace aplikace hybridních toků na webu Entra nebo webu Azure Portal nevybírejte u koncového bodu autorizace políčko pro vrácení přístupových tokenů nebo tokenů ID. Obslužná rutina OIDC automaticky požaduje příslušné tokeny pomocí kódu vráceného z autorizačního koncového bodu.

    oidcOptions.ResponseType = OpenIdConnectResponseType.Code;

  • MapInboundClaimsa konfigurace NameClaimType a : Mnoho serverů OIDC používá "name" a "role" místo výchozích hodnot SOAP/WS-Fed v ClaimTypesRoleClaimType. Pokud MapInboundClaims je nastavená hodnota false, obslužná rutina neprovádí mapování deklarací identity a názvy deklarací identity z JWT používají přímo aplikace. Následující příklad ručně mapuje deklarace identity názvu a role:

Poznámka:

MapInboundClaims musí být nastavena na false většinu zprostředkovatelů OIDC, což brání přejmenování deklarací identity.

oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = JwtRegisteredClaimNames.Name;
oidcOptions.TokenValidationParameters.RoleClaimType = "role";

  • Konfigurace cesty: Cesty musí odpovídat identifikátoru URI přesměrování (cesta zpětného volání přihlášení) a cestě k přesměrování odhlášení (cesta zpětného volání odhlášení) nakonfigurované při registraci aplikace u poskytovatele OIDC. Na webu Azure Portal se cesty konfigurují v okně Ověřování registrace aplikace. Přihlašovací i odhlašující cesty musí být zaregistrované jako identifikátory URI přesměrování. Výchozí hodnoty jsou /signin-oidc a /signout-callback-oidc.

    • CallbackPath: Cesta požadavku v rámci základní cesty aplikace, kde se vrátí uživatelský agent.

      Na webu Entra nebo Azure Portal nastavte cestu v identifikátoru URI přesměrování webové platformy:

      https://localhost/signin-oidc

      Poznámka:

      Pro adresy při použití ID Microsoft Entra se port nevyžaduje localhost . Většina ostatních zprostředkovatelů OIDC vyžaduje správný port.

    • SignedOutCallbackPath: Cesta požadavku v rámci základní cesty aplikace, kde se uživatelský agent vrátí po odhlášení od zprostředkovatele identity.

      Na webu Entra nebo Azure Portal nastavte cestu v identifikátoru URI přesměrování webové platformy:

      https://localhost/signout-callback-oidc

      Poznámka:

      Pro adresy při použití ID Microsoft Entra se port nevyžaduje localhost . Většina ostatních zprostředkovatelů OIDC vyžaduje správný port.

      Poznámka:

      Pokud používáte web společnosti Microsoft Identity , poskytovatel se v současné době přesměruje zpět na SignedOutCallbackPath adresu, pokud se používá autorita microsoftonline.com (https://login.microsoftonline.com/{TENANT ID}/v2.0/). Toto omezení neexistuje, pokud můžete použít "společnou" autoritu s webem Microsoftu Identity . Další informace najdete v tématu postLogoutRedirectUri nefunguje, pokud adresa URL autority obsahuje ID tenanta (AzureAD/microsoft-authentication-library-for-js #5783).

    • RemoteSignOutPath: Požadavky přijaté na této cestě způsobí, že obslužná rutina vyvolá odhlášení pomocí schématu odhlášení.

      Na webu Entra nebo Azure Portal nastavte adresu URL odhlášení front-channel:

      https://localhost/signout-oidc

      Poznámka:

      Pro adresy při použití ID Microsoft Entra se port nevyžaduje localhost . Většina ostatních zprostředkovatelů OIDC vyžaduje správný port.

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

    Příklady (výchozí hodnoty):

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

  • (Microsoft Azure pouze s běžným koncovým bodem): TokenValidationParameters.IssuerValidatorMnoho zprostředkovatelů OIDC pracuje s výchozím validátorem vystavitele, ale musíme počítat s parametrizovaným vystavitelem s ID tenanta ({TENANT ID}) vráceným https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Další informace najdete v tématu SecurityTokenInvalidIssuerException s OpenID Připojení a koncovým bodem Azure AD "common" (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

    Pouze pro aplikace používající Microsoft Entra ID nebo Azure AD B2C s "běžným" koncovým bodem:

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

Ukázkový kód aplikace

Zkontrolujte ukázkovou aplikaci a zkontrolujte následující funkce:

  • Automatická neinteraktivní aktualizace tokenů pomocí vlastního cookie aktualizačního modulu (CookieOidcRefresher.cs).
  • PersistingAuthenticationStateProvider Třída (PersistingAuthenticationStateProvider.cs) je serverová stranaAuthenticationStateProvider, která používá PersistentComponentState k toku stav ověřování do klienta, což je opraveno po dobu životnosti aplikace WebAssembly.
  • Příklady požadavků na Blazor webovou aplikaci pro data o počasí zpracovává koncový bod minimálního Program rozhraní API (/weather-forecast) v souboru (Program.cs). Koncový bod vyžaduje autorizaci voláním RequireAuthorization. Pro všechny kontrolery, které přidáte do projektu, přidejte [Authorize] atribut do kontroleru nebo akce.
  • Aplikace bezpečně volá (webové) rozhraní API v serverovém projektu pro data o počasí:
    • Při vykreslování Weather komponenty na serveru komponenta používá komponentu ServerWeatherForecaster na serveru k přímému získání dat o počasí (ne prostřednictvím volání webového rozhraní API).
    • Při vykreslení komponenty v klientovi používá ClientWeatherForecaster komponenta implementaci služby, která používá předkonfigurované HttpClient (v souboru klientského Program projektu) k volání webového rozhraní API do projektu serveru. Minimální koncový bod rozhraní API (/weather-forecast) definovaný v souboru projektu Program serveru získá data o počasí z ServerWeatherForecaster klienta a vrátí data klientovi.

Další informace o (webových) voláních rozhraní API pomocí abstrakcí služby ve Službě Web Apps najdete v Blazor tématu Volání webového rozhraní API z aplikace ASP.NET CoreBlazor.

Projekt webové aplikace na straně Blazor klienta (BlazorWebAppOidc.Client)

Projekt BlazorWebAppOidc.Client je projekt Blazor na straně klienta webové aplikace.

PersistentAuthenticationStateProvider Třída (PersistentAuthenticationStateProvider.cs) je na straně AuthenticationStateProvider klienta, která určuje stav ověřování uživatele vyhledáním dat uložených na stránce, když byla vykreslena na serveru. Stav ověřování je opraven po celou dobu životnosti aplikace WebAssembly.

Pokud se uživatel potřebuje přihlásit nebo odhlásit, vyžaduje se opětovné načtení celé stránky.

Ukázková aplikace poskytuje jenom uživatelské jméno a e-mail pro účely zobrazení. Nezahrnuje tokeny, které se ověřují na serveru při provádění následných požadavků, které fungují samostatně s využitím cookie požadavků, které jsou součástí požadavků na HttpClient server.

Tato verze článku popisuje implementaci OIDC se vzorem back-endu pro front-end (BFF). Pokud specifikace aplikace nevyvolá přijetí vzoru BFF, změňte selektor verze článku na OIDC bez vzoru BFF.

Probírá se následující specifikace:

  • Blazor Webová aplikace používá režim automatického vykreslování s globální interaktivitou.
  • Vlastní služby zprostředkovatele stavu ověřování používají serverové a klientské aplikace k zachycení stavu ověřování uživatele a jeho toku mezi serverem a klientem.
  • Tato aplikace je výchozím bodem pro jakýkoli tok ověřování OIDC. OIDC je v aplikaci nakonfigurovaný ručně a nespoléhá na microsoft Entra ID ani webové balíčky MicrosoftuIdentity, ani ukázková aplikace nevyžaduje hostování Microsoft Azure. Ukázková aplikace se ale může používat s entra, webem Microsoftu Identity a hostovanými v Azure.
  • Automatická neinteraktivní aktualizace tokenu
  • Model Back-endu pro front-end (BFF) se přijímá pomocí rozhraní .NET Aspire pro zjišťování služeb a YARP pro proxy požadavky na koncový bod předpovědi počasí v back-endové aplikaci.
    • Back-endové webové rozhraní API používá ověřování JWT-bearer k ověření tokenů JWT uložených Blazor webovou aplikací v přihlášení cookie.
    • Aspire zlepšuje prostředí vytváření aplikací nativních pro cloud .NET. Poskytuje konzistentní sadu nástrojů a vzorů pro vytváření a spouštění distribuovaných aplikací.
    • YARP (další reverzní proxy server) je knihovna, která slouží k vytvoření reverzního proxy serveru.

Upozornění balíčku ve verzi Preview

Upozorňující

Technologie a balíčky používané BlazorWebAppOidcBff ukázkovou aplikací a popsané v tomto článku jsou v současnosti ve verzi Preview. Obsah článku, rozhraní API a ukázková aplikace se v tuto chvíli nepodporují a v současné době se nedoporučuje používat v produkčním prostředí. Ukázková aplikace a pokyny se můžou bez předchozího upozornění změnit.

Požadavek

.NET Aspire vyžaduje Visual Studio verze 17.10 nebo novější.

Ukázková aplikace

Ukázková aplikace se skládá z pěti projektů:

  • .NET Aspire:
    • Aspire.AppHost: Slouží ke správě aspektů orchestrace vysoké úrovně aplikace.
    • Aspire.ServiceDefaults: Obsahuje výchozí konfigurace aplikací .NET Aspire, které je možné podle potřeby rozšířit a přizpůsobit.
  • MinimalApiJwt: Back-endové webové rozhraní API, které obsahuje příklad koncového bodu rozhraní API pro data o počasí.
  • BlazorWebAppOidc: Projekt Blazor na straně serveru webové aplikace.
  • BlazorWebAppOidc.Client: Projekt Blazor na straně klienta webové aplikace.

Pomocí následujícího odkazu přejděte k ukázkovým aplikacím prostřednictvím složky nejnovější verze z kořenového adresáře úložiště. Projekty jsou ve BlazorWebAppOidcBff složce pro .NET 8 nebo novější.

Zobrazení nebo stažení ukázkového kódu (postup stažení)

Projekty .NET Aspire

Další informace o používání rozhraní .NET Aspire a podrobnosti o .AppHost.ServiceDefaults projektech ukázkové aplikace najdete v dokumentaci k .NET Aspire.

Ověřte, že jste splnili požadavky pro .NET Aspire. Další informace najdete v části Požadavky v rychlém startu : Sestavení první aplikace .NET Aspire.

Projekt webové aplikace na straně Blazor serveru (BlazorWebAppOidc)

Projekt BlazorWebAppOidc je projekt Blazor na straně serveru webové aplikace. Projekt používá YARP k proxy žádostem o koncový bod předpovědi počasí v projektu back-endového webového rozhraní API (MinimalApiJwt) s uloženým access_token v ověřování cookie.

Soubor BlazorWebAppOidc.http lze použít k testování žádosti o data o počasí. Mějte na paměti, že projekt BlazorWebAppOidc musí být spuštěn pro otestování koncového bodu a koncový bod je pevně zakódovaný do souboru. Další informace naleznete v tématu Použití souborů .http v sadě Visual Studio 2022.

Poznámka:

Serverový projekt používá IHttpContextAccessor/HttpContext, ale nikdy pro interaktivně vykreslené komponenty. Další informace najdete v tématu Pokyny ke zmírnění hrozeb pro vykreslování na straně serveru ASP.NET CoreBlazor.

Konfigurace

Tato část vysvětluje, jak nakonfigurovat ukázkovou aplikaci.

Poznámka:

Pro Microsoft Entra ID a Azure AD B2C můžete použít z webu Microsoftu Identity (Microsoft.Identity.Webbalíček NuGet, dokumentace k rozhraní API), který přidá obslužné rutiny OIDC i Cookie ověřování s příslušnými výchozími nastaveními.AddMicrosoftIdentityWebApp Ukázková aplikace a pokyny v této části nepoužívají web Microsoftu Identity . Pokyny ukazují, jak RUČNĚ nakonfigurovat obslužnou rutinu OIDC pro libovolného zprostředkovatele OIDC. Další informace o implementaci webu společnosti Microsoft Identity naleznete v odkazovaných prostředcích.

Následující OpenIdConnectOptions konfigurace se nachází v souboru projektu Program při volání AddOpenIdConnect:

  • SignInScheme: Nastaví schéma ověřování odpovídající middlewaru zodpovědnému za zachování identity uživatele po úspěšném ověření. Obslužná rutina OIDC musí používat schéma přihlašování, které dokáže uchovávat přihlašovací údaje uživatelů napříč požadavky. Následující řádek je k dispozici pouze pro demonstrační účely. Pokud tuto hodnotu vynecháte, DefaultSignInScheme použije se jako záložní hodnota.

    oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;

  • Obory pro openid a profile () (Scopevolitelné): Obory openid a profile obory jsou také ve výchozím nastavení nakonfigurované, protože jsou vyžadovány pro fungování obslužné rutiny OIDC, ale pokud jsou obory zahrnuté v Authentication:Schemes:MicrosoftOidc:Scope konfiguraci, může být potřeba je znovu přidat. Obecné pokyny ke konfiguraci najdete v tématu Konfigurace v konfiguraci ASP.NET Core a ASP.NET CoreBlazor.

    oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);

  • SaveTokens: Definuje, jestli mají být po úspěšné autorizaci uloženy AuthenticationProperties přístupové a obnovovací tokeny. Hodnota je nastavená na true ověření požadavků na data o počasí z projektu back-endového webového rozhraní API (MinimalApiJwt).

    oidcOptions.SaveTokens = true;

  • Rozsah pro offline přístup (Scope): Obor offline_access je vyžadován pro obnovovací token.

    oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

  • Obory pro získání dat o počasí z webového rozhraní API (Scope): Obor Weather.Get je nakonfigurovaný na portálu Azure nebo Entra v části Vystavení rozhraní API. To je nezbytné pro projekt back-endového webového rozhraní API (MinimalApiJwt) k ověření přístupového tokenu pomocí nosné JWT.

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

    Příklad:

    • Identifikátor URI ID aplikace ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
      • Název adresáře ({DIRECTORY NAME}): contoso
      • ID{CLIENT ID} aplikace (klienta): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
    • Rozsah nakonfigurovaný pro data o počasí z MinimalApiJwt ({API NAME}): Weather.Get
    oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f/Weather.Get");

    Předchozí příklad se týká aplikace zaregistrované v tenantovi s typem tenanta AAD B2C. Pokud je aplikace zaregistrovaná v tenantovi ME-ID, identifikátor URI ID aplikace se liší, a proto se rozsah liší.

    Příklad:

    • Identifikátor URI ID aplikace ({APP ID URI}): api://{CLIENT ID} s ID aplikace (klient) ({CLIENT ID}): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
    • Rozsah nakonfigurovaný pro data o počasí z MinimalApiJwt ({API NAME}): Weather.Get
    oidcOptions.Scope.Add("api://4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f/Weather.Get");

  • Authority a ClientId: Nastaví autoritu a ID klienta pro volání OIDC.

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

    Příklad:

    • Autorita (): https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ ({AUTHORITY}používá ID a3942615-d115-4eb7-bc84-9974abcf5064tenanta)
    • ID klienta ({CLIENT ID}): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
    oidcOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";
oidcOptions.ClientId = "4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";

    Příklad pro "běžnou" autoritu Microsoft Azure:

    Pro aplikace s více tenanty by se měla používat "společná" autorita. Můžete také použít "společnou" autoritu pro aplikace s jedním tenantem, ale vyžaduje se vlastní IssuerValidator , jak je znázorněno dále v této části.

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

  • ClientSecret: Tajný klíč klienta OIDC.

    Následující příklad je určen pouze pro účely testování a demonstrací. Neukládejte tajný kód klienta do sestavení aplikace ani tajný kód nekontrolujte do správy zdrojového kódu. Uložte tajný klíč klienta do tajných kódů uživatelů, azure Key Vaultu nebo proměnné prostředí.

    Konfigurace schématu ověřování se automaticky čte z builder.Configuration["Authentication:Schemes:{SCHEME NAME}:{PropertyName}"], kde {SCHEME NAME} zástupný symbol je schéma, což je MicrosoftOidc ve výchozím nastavení. Vzhledem k tomu, že konfigurace je předkonfigurovaná, je možné tajný klíč klienta automaticky číst prostřednictvím konfiguračního Authentication:Schemes:MicrosoftOidc:ClientSecret klíče. Na serveru pomocí proměnných prostředí pojmenujte proměnnou Authentication__Schemes__MicrosoftOidc__ClientSecretprostředí:

    set Authentication__Schemes__MicrosoftOidc__ClientSecret={CLIENT SECRET}

    Pouze pro ukázku ClientSecret a testování lze nastavit přímo. Nenastavujte hodnotu přímo pro nasazené produkční aplikace. V případě mírně vylepšeného zabezpečení podmíněně zkompilujte řádek se DEBUG symbolem:

    #if DEBUG
oidcOptions.ClientSecret = "{CLIENT SECRET}";
#endif

    Příklad:

    Tajný klíč klienta ({CLIENT SECRET}): 463471c8c4...f90d674bc9 (zkrácený pro zobrazení)

    #if DEBUG
oidcOptions.ClientSecret = "463471c8c4...137f90d674bc9";
#endif

  • ResponseType: Nakonfiguruje obslužnou rutinu OIDC tak, aby prováděla pouze tok autorizačního kódu. Implicitní granty a hybridní toky nejsou v tomto režimu zbytečné.

    V konfiguraci implicitního udělení a registrace aplikace hybridních toků na webu Entra nebo webu Azure Portal nevybírejte u koncového bodu autorizace políčko pro vrácení přístupových tokenů nebo tokenů ID. Obslužná rutina OIDC automaticky požaduje příslušné tokeny pomocí kódu vráceného z autorizačního koncového bodu.

    oidcOptions.ResponseType = OpenIdConnectResponseType.Code;

  • MapInboundClaimsa konfigurace NameClaimType a : Mnoho serverů OIDC používá "name" a "role" místo výchozích hodnot SOAP/WS-Fed v ClaimTypesRoleClaimType. Pokud MapInboundClaims je nastavená hodnota false, obslužná rutina neprovádí mapování deklarací identity a názvy deklarací identity z JWT používají přímo aplikace. Následující příklad ručně mapuje deklarace identity názvu a role:

Poznámka:

MapInboundClaims musí být nastavena na false většinu zprostředkovatelů OIDC, což brání přejmenování deklarací identity.

oidcOptions.MapInboundClaims = false;
oidcOptions.TokenValidationParameters.NameClaimType = JwtRegisteredClaimNames.Name;
oidcOptions.TokenValidationParameters.RoleClaimType = "role";

  • Konfigurace cesty: Cesty musí odpovídat identifikátoru URI přesměrování (cesta zpětného volání přihlášení) a cestě k přesměrování odhlášení (cesta zpětného volání odhlášení) nakonfigurované při registraci aplikace u poskytovatele OIDC. Na webu Azure Portal se cesty konfigurují v okně Ověřování registrace aplikace. Přihlašovací i odhlašující cesty musí být zaregistrované jako identifikátory URI přesměrování. Výchozí hodnoty jsou /signin-oidc a /signout-callback-oidc.

    • CallbackPath: Cesta požadavku v rámci základní cesty aplikace, kde se vrátí uživatelský agent.

      Na webu Entra nebo Azure Portal nastavte cestu v identifikátoru URI přesměrování webové platformy:

      https://localhost/signin-oidc

      Poznámka:

      Pro adresy se nevyžaduje localhost port.

    • SignedOutCallbackPath: Cesta požadavku v rámci základní cesty aplikace, kde se uživatelský agent vrátí po odhlášení od zprostředkovatele identity.

      Na webu Entra nebo Azure Portal nastavte cestu v identifikátoru URI přesměrování webové platformy:

      https://localhost/signout-callback-oidc

      Poznámka:

      Pro adresy se nevyžaduje localhost port.

      Poznámka:

      Pokud používáte web společnosti Microsoft Identity , poskytovatel se v současné době přesměruje zpět na SignedOutCallbackPath adresu, pokud se používá autorita microsoftonline.com (https://login.microsoftonline.com/{TENANT ID}/v2.0/). Toto omezení neexistuje, pokud můžete použít "společnou" autoritu s webem Microsoftu Identity . Další informace najdete v tématu postLogoutRedirectUri nefunguje, pokud adresa URL autority obsahuje ID tenanta (AzureAD/microsoft-authentication-library-for-js #5783).

    • RemoteSignOutPath: Požadavky přijaté na této cestě způsobí, že obslužná rutina vyvolá odhlášení pomocí schématu odhlášení.

      Na webu Entra nebo Azure Portal nastavte adresu URL odhlášení front-channel:

      https://localhost/signout-oidc

      Poznámka:

      Pro adresy se nevyžaduje localhost port.

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

    Příklady (výchozí hodnoty):

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

  • (Microsoft Azure pouze s běžným koncovým bodem): TokenValidationParameters.IssuerValidatorMnoho zprostředkovatelů OIDC pracuje s výchozím validátorem vystavitele, ale musíme počítat s parametrizovaným vystavitelem s ID tenanta ({TENANT ID}) vráceným https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Další informace najdete v tématu SecurityTokenInvalidIssuerException s OpenID Připojení a koncovým bodem Azure AD "common" (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

    Pouze pro aplikace používající Microsoft Entra ID nebo Azure AD B2C s "běžným" koncovým bodem:

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

Ukázkový kód aplikace

Zkontrolujte ukázkovou aplikaci a zkontrolujte následující funkce:

  • Automatická neinteraktivní aktualizace tokenů pomocí vlastního cookie aktualizačního modulu (CookieOidcRefresher.cs).
  • PersistingAuthenticationStateProvider Třída (PersistingAuthenticationStateProvider.cs) je serverová stranaAuthenticationStateProvider, která používá PersistentComponentState k toku stav ověřování do klienta, což je opraveno po dobu životnosti aplikace WebAssembly.
  • Požadavky na Blazor webovou aplikaci se proxiují do projektu back-endového webového rozhraní API (MinimalApiJwt). MapForwarderProgram v souboru přidává přímé předávání požadavků HTTP, které odpovídají zadanému vzoru konkrétnímu cíli, pomocí výchozí konfigurace odchozího požadavku, přizpůsobených transformací a výchozího klienta HTTP:
    • Při vykreslování Weather komponenty na serveru tato komponenta používá ServerWeatherForecaster k proxy žádosti o data o počasí pomocí přístupového tokenu uživatele.
    • Při vykreslení komponenty v klientovi používá ClientWeatherForecaster komponenta implementaci služby, která používá předkonfigurované HttpClient (v souboru klientského Program projektu) k volání webového rozhraní API do projektu serveru. Minimální koncový bod rozhraní API (/weather-forecast) definovaný v souboru projektu Program serveru transformuje požadavek pomocí přístupového tokenu uživatele k získání dat o počasí.

Další informace o (webových) voláních rozhraní API pomocí abstrakcí služby ve Službě Web Apps najdete v Blazor tématu Volání webového rozhraní API z aplikace ASP.NET CoreBlazor.

Projekt webové aplikace na straně Blazor klienta (BlazorWebAppOidc.Client)

Projekt BlazorWebAppOidc.Client je projekt Blazor na straně klienta webové aplikace.

PersistentAuthenticationStateProvider Třída (PersistentAuthenticationStateProvider.cs) je na straně AuthenticationStateProvider klienta, která určuje stav ověřování uživatele vyhledáním dat uložených na stránce, když byla vykreslena na serveru. Stav ověřování je opraven po celou dobu životnosti aplikace WebAssembly.

Pokud se uživatel potřebuje přihlásit nebo odhlásit, vyžaduje se opětovné načtení celé stránky.

Ukázková aplikace poskytuje jenom uživatelské jméno a e-mail pro účely zobrazení. Nezahrnuje tokeny, které se ověřují na serveru při provádění následných požadavků, které fungují samostatně s využitím cookie požadavků, které jsou součástí požadavků na HttpClient server.

Projekt back-endového webového rozhraní API (MinimalApiJwt)

Projekt MinimalApiJwt je back-endové webové rozhraní API pro více front-endových projektů. Projekt nakonfiguruje minimální koncový bod rozhraní API pro data o počasí. Požadavky z Blazor projektu na straně serveru webové aplikace (BlazorWebAppOidc) se proxiují do MinimalApiJwt projektu.

Konfigurace

Nakonfigurujte projekt v JwtBearerOptionsAddJwtBearer volání v souboru projektu Program :

  • Audience: Nastaví cílovou skupinu pro jakýkoli přijatý token OpenID Připojení.

    Na portálu Azure nebo Entra: Porovná hodnotu pouze s cestou identifikátoru URI ID aplikace nakonfigurovaného při přidání Weather.Get oboru v části Vystavení rozhraní API:

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

    Příklad:

    Identifikátor URI ID aplikace ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}

    • Název adresáře ({DIRECTORY NAME}): contoso
    • ID{CLIENT ID} aplikace (klienta): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f
    jwtOptions.Audience = "https://contoso.onmicrosoft.com/4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";

    Předchozí příklad se týká aplikace zaregistrované v tenantovi s typem tenanta AAD B2C. Pokud je aplikace zaregistrovaná v tenantovi ME-ID, identifikátor URI ID aplikace se liší, a proto se cílová skupina liší.

    Příklad:

    Identifikátor URI ID aplikace ({APP ID URI}): api://{CLIENT ID} s ID aplikace (klient) ({CLIENT ID}): 4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f

    jwtOptions.Audience = "api://4ba4de56-9cef-45d9-83fa-a4c18f9f5f0f";

  • Authority: Nastaví autoritu pro provádění volání OpenID Připojení. Porovná hodnotu s autoritou nakonfigurovanou pro obslužnou rutinu OIDC v BlazorWebAppOidc/Program.cs:

    jwtOptions.Authority = "{AUTHORITY}";

    Příklad:

    Autorita (): https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/ ({AUTHORITY}používá ID a3942615-d115-4eb7-bc84-9974abcf5064tenanta)

    jwtOptions.Authority = "https://login.microsoftonline.com/a3942615-d115-4eb7-bc84-9974abcf5064/v2.0/";

    Předchozí příklad se týká aplikace zaregistrované v tenantovi s typem tenanta AAD B2C. Pokud je aplikace zaregistrovaná v tenantovi ME-ID, měla by se autorita shodovat s issurerem (iss) JWT vráceným poskytovatelem identity:

    jwtOptions.Authority = "https://sts.windows.net/a3942615-d115-4eb7-bc84-9974abcf5064/";

Minimální rozhraní API pro data o počasí

Zabezpečený koncový bod pro předpověď počasí v souboru projektu Program :

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 rozšíření vyžaduje autorizaci pro definici trasy. Pro všechny kontrolery, které přidáte do projektu, přidejte [Authorize] atribut do kontroleru nebo akce.

Přesměrování na domovskou stránku při odhlášení

Když uživatel přejde kolem aplikace, LogInOrOut komponenta (Layout/LogInOrOut.razor) nastaví skryté pole pro zpáteční adresu URL (ReturnUrl) na hodnotu aktuální adresy URL (currentURL). Když se uživatel z aplikace odhlásí, zprostředkovatel identity ho vrátí na stránku, ze které se odhlásil.

Pokud se uživatel odhlásí ze zabezpečené stránky, vrátí se po odhlášení zpět na stejnou zabezpečenou stránku, aby se odeslal zpět prostřednictvím procesu ověřování. Toto chování je v pořádku, když uživatelé potřebují často přepínat účty. Alternativní specifikace aplikace ale může volat, aby se uživatel po odhlášení vrátil na domovskou stránku aplikace nebo na jinou stránku. Následující příklad ukazuje, jak nastavit domovskou stránku aplikace jako zpáteční adresu URL pro operace odhlášení.

Důležité změny LogInOrOut komponenty jsou znázorněny v následujícím příkladu. Skryté value pole je ReturnUrl nastaveno na domovskou stránku na /adrese . IDisposable už není implementovaný. Ten NavigationManager se už nenasadí. Celý @code blok se odebere.

Layout/LogInOrOut.razor:

@using Microsoft.AspNetCore.Authorization

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <input type="hidden" name="ReturnUrl" value="/" />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout @context.User.Identity?.Name
                </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>

Kryptografická nešifrovaná

Nonce je řetězcová hodnota, která přidruží relaci klienta k tokenu ID pro zmírnění útoků přehrání.

Pokud při vývoji a testování ověřování dojde k chybě, použijte pro každé testovací spuštění novou relaci prohlížeče InPrivate nebo incognito, bez ohledu na to, jak malá je změna provedená v aplikaci nebo testovacím uživateli, protože zastaralá data můžou vést k nečekané cookie chybě. Další informace najdete v Cookiečásti s a daty webu.

Nepožaduje se ani nepoužívá, když se obnovovací token vymění za nový přístupový token. V ukázkové aplikaci CookieOidcRefresher se (CookieOidcRefresher.cs) záměrně nastaví OpenIdConnectProtocolValidator.RequireNonce na false.

Odstraňování potíží

Protokolování

Serverová aplikace je standardní aplikace ASP.NET Core. Informace o povolení nižší úrovně protokolování v serverové aplikaci najdete v pokynech k protokolování ASP.NET Core.

Pokud chcete povolit protokolování ladění nebo trasování pro Blazor WebAssembly ověřování, přečtěte si část Protokolování ověřování na straně klienta protokolování ASP.NET Core Blazor pomocí selektoru verze článku nastaveného na ASP.NET Core 7.0 nebo novější.

Běžné chyby

  • Chybná konfigurace aplikace nebo Identity poskytovatele (IP)

    Nejčastější chyby jsou způsobené nesprávnou konfigurací. Tady je několik příkladů:

    • V závislosti na požadavcích scénáře brání chybějící nebo nesprávné autoritě, instanci, ID tenanta, doméně tenanta, ID klienta nebo identifikátoru URI přesměrování, aby aplikace ověřoval klienty.
    • Nesprávné obory požadavků brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
    • Nesprávná nebo chybějící oprávnění rozhraní API serveru brání klientům v přístupu ke koncovým bodům webového rozhraní API serveru.
    • Spuštění aplikace na jiném portu, než je nakonfigurované v identifikátoru URI přesměrování registrace aplikace IP adresy. Všimněte si, že port není nutný pro MICROSOFT Entra ID a aplikaci spuštěnou localhost na adrese pro testování vývoje, ale konfigurace portu aplikace a port, na kterém je aplikace spuštěná, se musí shodovat s neadresoulocalhost .

    Pokrytí konfigurace v tomto článku ukazuje příklady správné konfigurace. Pečlivě zkontrolujte konfiguraci, která hledá aplikaci a nesprávnou konfiguraci IP adres.

    Pokud se konfigurace zobrazí správně:

    • Analyzujte protokoly aplikace.

    • Prozkoumejte síťový provoz mezi klientskou aplikací a IP nebo serverovou aplikací pomocí vývojářských nástrojů prohlížeče. Často je přesná chybová zpráva nebo zpráva s povědomím o příčině problému vrácena klientovi ip adresou nebo serverovou aplikací po provedení požadavku. Vývojářské nástroje pokyny najdete v následujících článcích:

    Tým dokumentace reaguje na zpětnou vazbu a chyby v článcích (otevřete problém z oddílu Pro zpětnou vazbu na této stránce ), ale nemůže poskytnout podporu k produktům. K dispozici je několik veřejných fór podpory, která vám pomůžou s řešením potíží s aplikací. Doporučujeme následující:

    Předchozí fóra nejsou vlastněna ani řízena Společností Microsoft.

    V případě zpráv o chybách rozhraní bez zabezpečení, nerozlišujících a nedůvěryhodných reprodukovatelných chyb otevřete problém s produktovou jednotkou ASP.NET Core. Neotevírejte problém s produktovou jednotkou, dokud důkladně neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nedokáže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je sestava citlivá nebo důvěrná v povaze nebo popisuje potenciální chybu zabezpečení v produktu, který by útočníci mohli zneužít, přečtěte si téma Hlášení problémů se zabezpečením a chyb (dotnet/aspnetcore úložiště GitHub).</a0>

  • Neautorizovaný klient pro ME-ID

    info: Autorizace Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] selhala. Tyto požadavky nebyly splněny: DenyAnonymousAuthorizationRequirement: Vyžaduje ověřeného uživatele.

    Chyba zpětného volání přihlášení z ME-ID:

    • Chyba: unauthorized_client
    • Popis: AADB2C90058: The provided application is not configured to allow public clients.

    Řešení chyby:

    1. Na webu Azure Portal přejděte k manifestu aplikace.
    2. allowPublicClient Nastavte atribut na null nebo true.

Cookies a data lokality

Cookiedata s a webu můžou přetrvat v aktualizacích aplikací a kolidovat s testováním a odstraňováním potíží. Při provádění změn kódu aplikace, změn uživatelského účtu u poskytovatele nebo změn konfigurace aplikace poskytovatele zrušte následující:

  • Přihlášení cookieuživatele
  • Aplikace cookie
  • Uložená a uložená data lokality v mezipaměti

Jedním z přístupů, jak zabránit tomu, aby se při testování a řešení potíží zabránilo přetrvávání cookiedat lokality, je:

  • Konfigurace prohlížeče
    • K testování můžete použít prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna cookie data a data webu.
    • Ujistěte se, že je prohlížeč zavřený ručně nebo integrované vývojové prostředí (IDE) pro všechny změny aplikace, testovacího uživatele nebo konfigurace poskytovatele.
  • Pomocí vlastního příkazu otevřete prohlížeč v režimu InPrivate nebo Incognito v sadě Visual Studio:
    • V dialogovém okně Spustit v sadě Visual Studio otevřete dialogové okno Procházet.
    • Vyberte tlačítko Přidat.
    • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný v jiném umístění nebo nepoužíváte Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
      • 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
    • V poli Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v režimu InPrivate nebo Anonymní režim. Některé prohlížeče vyžadují adresu URL aplikace.
      • Microsoft Edge: Použijte -inprivate.
      • Google Chrome: Použijte --incognito --new-window {URL}, kde zástupný symbol {URL} je adresa URL k otevření (například https://localhost:5001).
      • Mozilla Firefox: Použijte -private -url {URL}, kde zástupný symbol {URL} je adresa URL k otevření (například https://localhost:5001).
    • Do pole Popisný název zadejte název. Například Firefox Auth Testing.
    • Vyberte tlačítko OK.
    • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí tlačítkem Nastavit jako výchozí .
    • Ujistěte se, že integrované vývojové prostředí (IDE) zavřel prohlížeč pro všechny změny aplikace, testovacího uživatele nebo konfigurace poskytovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu sady .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

  1. Vymažte mezipaměti balíčků NuGet místního systému spuštěním dotnet nuget locals all --clear z příkazového prostředí.
  2. Odstraňte složky a obj složky projektubin.
  3. Obnovte a znovu sestavte projekt.
  4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Poznámka:

Použití verzí balíčků nekompatibilních s cílovou architekturou aplikace se nepodporuje. Informace o balíčku potřebujete pomocí galerie NuGet nebo Průzkumníka balíčků FuGet.

Spuštění serverové aplikace

Při testování a řešení potíží s Blazor webovou aplikací se ujistěte, že aplikaci spouštíte z projektu serveru.

Kontrola uživatele

Následující UserClaims komponentu lze použít přímo v aplikacích nebo sloužit jako základ pro další přizpůsobení.

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.Count() > 0)
{
    <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;
    }
}

Další materiály