Zabezpečení hostované aplikace ASP.NET Core Blazor WebAssembly pomocí Identity serveru

Článek
11/12/2024

Důležité

Šablona projektu Hostovaná Blazor WebAssembly byla z rozhraní odebrána s vydáním rozhraní .NET 8 (listopad 2023). Pokyny v tomto článku jsou podporovány pouze pro .NET 7 nebo starší. Hostované Blazor WebAssembly aplikace, které jsou upgradovány v každé verzi, budou nadále dostávat podporu produktů. Alternativně refaktorujte aplikaci do samostatné aplikace Blazor WebAssembly nebo Blazor Web App.

Tento článek vysvětluje, jak vytvořit hostované Blazor WebAssembly řešení , které k ověřování uživatelů a volání rozhraní API používá Duende Identity Server .

Důležité

Duende Software může vyžadovat, abyste zaplatili licenční poplatek za produkční využití serveru Duende Identity Server. Další informace najdete v tématu Migrace z ASP.NET Core 5.0 na verzi 6.0.

Poznámka:

Pokud chcete nakonfigurovat samostatnou nebo hostované Blazor WebAssembly aplikaci tak, aby používala existující externí Identity instanci serveru, postupujte podle pokynů v tématu Zabezpečení samostatné aplikace ASP.NET Core Blazor WebAssembly pomocí knihovny ověřování.

Pro další pokrytí scénářů zabezpečení po přečtení tohoto článku viz ASP.NET Core Blazor WebAssembly další scénáře zabezpečení.

Průvodce

Pododdíly návodu vysvětlují, jak:

Blazor Vytvoření aplikace
Spustit aplikaci

Vytvoření nového Blazor WebAssembly projektu pomocí mechanismu ověřování:

Vytvoření nového projektu
Blazor WebAssembly Zvolte šablonu aplikace. Vyberte Další.
Zadejte název projektu bez použití pomlček. Ověřte správnost umístění . Vyberte Další.

Nepoužívejte pomlčky (-) v názvu projektu, které přeruší vytvoření identifikátoru aplikace OIDC. Logika v Blazor WebAssembly šabloně projektu používá název projektu pro identifikátor aplikace OIDC v konfiguraci řešení a pomlčky nejsou povoleny v identifikátoru aplikace OIDC. Pascalova konvence (BlazorSample) nebo podtržítka (Blazor_Sample) jsou přijatelné alternativy.
V dialogovém okně Další informace vyberte Jednotlivé účty jako typ ověřování pro ukládání uživatelů v aplikaci pomocí systému ASP.NET CoreIdentity.
Vyberte políčko ASP.NET Core Hosted.
Vyberte tlačítko Vytvořit a vytvořte aplikaci.

Pokud chcete vytvořit nový Blazor WebAssembly projekt s ověřovacím mechanismem v prázdné složce, zadejte Individual mechanismus ověřování s -au|--auth možností ukládat uživatele v aplikaci pomocí systému ASP.NET Core Identity :

dotnet new blazorwasm -au Individual -ho -o {PROJECT NAME}

Zástupný symbol	Příklad
`{PROJECT NAME}`	`BlazorSample`

Výstupní umístění zadané pomocí volitelné -o|--output možnosti vytvoří složku projektu, pokud neexistuje, a stane se součástí názvu projektu.

Nepoužívejte pomlčky (-) v názvu projektu, které přeruší vytvoření identifikátoru aplikace OIDC. Logika v Blazor WebAssembly šabloně projektu používá název projektu pro identifikátor aplikace OIDC v konfiguraci řešení a pomlčky nejsou povoleny v identifikátoru aplikace OIDC. Argumenty typu Pascal () nebo podtržítka (BlazorSampleBlazor_Sample) jsou přijatelné alternativy.

Další informace najdete v popisu příkazu dotnet new v příručce k .NET Core.

Spustit aplikaci

Spusťte aplikaci z Server projektu. Při použití sady Visual Studio, buď:

Vyberte šipku rozbalovací nabídky vedle tlačítka Spustit. Otevřete Konfigurovat spuštěcí projekty z rozevíracího seznamu. Vyberte možnost Jeden počáteční projekt. Potvrďte nebo změňte počáteční projekt na projekt Server.
Než aplikaci spustíte, ověřte, že projekt Server je zvýrazněn v Průzkumník řešení jedním z následujících způsobů:
- Vyberte tlačítko Run (Spustit).
- Použijte z nabídky Ladění>Spustit ladění.
- Stiskněte klávesu F5.
V příkazovém prostředí přejděte do Server složky projektu řešení. Spusťte příkaz dotnet watch (nebo dotnet run).

Části řešení

Tato část popisuje části řešení vygenerované ze Blazor WebAssembly šablony projektu a popisuje způsob konfigurace řešení Client a Server projektů pro referenci. Pokud jste aplikaci vytvořili pomocí pokynů v části Návod , není v této části potřeba postupovat podle konkrétních pokynů. Pokyny v této části jsou užitečné pro aktualizaci aplikace pro ověřování a autorizaci uživatelů. Alternativním přístupem k aktualizaci aplikace je ale vytvoření nové aplikace z pokynů v části Návod a přesun komponent, tříd a prostředků aplikace do nové aplikace.

Server služby aplikace

Tato část se týká aplikace řešení Server .

Zaregistrují se následující služby.

V souboru Program:

Entity Framework Core a ASP.NET Core Identity:

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlite( ... ));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<ApplicationUser>(options => 
        options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

Identity Server s další AddApiAuthorization pomocnou metodou, která nastavuje výchozí konvence jádra ASP.NET nad Identity serverem:
```
builder.Services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
```
Ověřování pomocí další AddIdentityServerJwt pomocné metody, která nakonfiguruje aplikaci tak, aby ověřila tokeny JWT vytvořené serverem Identity :
```
builder.Services.AddAuthentication()
    .AddIdentityServerJwt();
```

V Startup.ConfigureServices z Startup.cs:
- Entity Framework Core a ASP.NET Core Identity:
```
services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlite(
        Configuration.GetConnectionString("DefaultConnection")));

services.AddDefaultIdentity<ApplicationUser>(options => 
        options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
```
  Varování
  
  Neukládejte tajné kódy aplikací, připojovací řetězec, přihlašovací údaje, hesla, osobní identifikační čísla (PIN), privátní kód C#/.NET nebo privátní klíče/tokeny v kódu na straně klienta, což je vždy nezabezpečené. Ve zkušebním a produkčním prostředí by kód na straně serveru a webová rozhraní API měly používat bezpečné ověřovací toky, které se vyhýbají ukládání přihlašovacích údajů v kódu projektu nebo v konfiguračních souborech. Mimo místní testování vývoje doporučujeme vyhnout se použití proměnných prostředí k ukládání citlivých dat, protože proměnné prostředí nejsou nejbezpečnějším přístupem. Pro místní testování vývoje se pro zabezpečení citlivých dat doporučuje nástroj Secret Manager. Další informace najdete v tématu Bezpečné udržování citlivých dat a přihlašovacích údajů.
- Identity Server s další AddApiAuthorization pomocnou metodou, která nastavuje výchozí konvence jádra ASP.NET nad Identity serverem:
```
services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
```
- Ověřování pomocí další AddIdentityServerJwt pomocné metody, která nakonfiguruje aplikaci tak, aby ověřila tokeny JWT vytvořené serverem Identity :
```
services.AddAuthentication()
    .AddIdentityServerJwt();
```

Poznámka:

Při registraci jednoho schématu ověřování se schéma ověřování automaticky použije jako výchozí schéma aplikace a není nutné schéma uvést do AddAuthentication nebo přes AuthenticationOptions. Další informace najdete v tématu Přehled ASP.NET základního ověřování a oznámení ASP.NET Core (aspnet/Oznámení č. 490).

V souboru Program:

V Startup.Configure z Startup.cs:

Middleware serveru Identity zveřejňuje koncové body OpenID Connect (OIDC):
```
app.UseIdentityServer();
```

Middleware Authentication je zodpovědné za ověřování přihlašovacích údajů v žádosti a nastavení uživatele v rámci kontextu žádosti.
```
app.UseAuthentication();
```

Middleware pro autorizaci umožňuje funkce autorizace.
```
app.UseAuthorization();
```

Autorizace rozhraní API

Tato část se týká aplikace řešení Server .

Pomocná AddApiAuthorization metoda konfiguruje Identity Server pro scénáře ASP.NET Core. Identity Server je výkonná a rozšiřitelná architektura pro zpracování problémů se zabezpečením aplikací. Identity Server zveřejňuje zbytečné složitosti pro nejběžnější scénáře. V důsledku toho je k dispozici sada konvencí a možností konfigurace, kterou považujeme za dobrý výchozí bod. Jakmile se vaše ověřování změní, je k dispozici plný výkon Identity serveru, který přizpůsobí ověřování tak, aby vyhovoval požadavkům aplikace.

Přidejte obslužnou rutinu ověřování pro rozhraní API, které spoluexistuje se serverem Identity

Tato část se týká aplikace řešení Server .

Pomocná AddIdentityServerJwt metoda nakonfiguruje schéma zásad pro aplikaci jako výchozí obslužnou rutinu ověřování. Zásada je nakonfigurovaná tak, aby umožňovala Identity zpracovávat všechny požadavky směrované na jakoukoli dílčí cestu v prostoru adresy URL pod /Identity. JwtBearerHandler zpracovává všechny ostatní požadavky. Kromě toho tato metoda:

Zaregistruje prostředek rozhraní API na Identity serveru s výchozím oborem {PROJECT NAME}API, kde je zástupný symbol {PROJECT NAME} název projektu při tvorbě aplikace.
Nakonfiguruje middleware nosných tokenů JWT tak, aby ověřil tokeny vydané serverem Identity pro aplikaci.

Kontroler předpovědi počasí

Tato část se týká aplikace řešení Server .

V WeatherForecastController (Controllers/WeatherForecastController.cs) je atribut [Authorize] použit pro třídu. Atribut označuje, že uživatel musí být autorizovaný na základě výchozí zásady pro přístup k prostředku. Výchozí zásady autorizace jsou nakonfigurovány tak, aby používaly výchozí schéma ověřování, které je nastaveno AddIdentityServerJwt. Pomocná metoda konfiguruje JwtBearerHandler jako výchozí obslužnou rutinu pro požadavky na aplikaci.

Kontext databáze aplikace

Tato část se týká aplikace řešení Server .

ApplicationDbContext V části (Data/ApplicationDbContext.cs) DbContext se rozšiřuje ApiAuthorizationDbContext<TUser> o zahrnutí schématu pro Identity server. ApiAuthorizationDbContext<TUser> je odvozen z IdentityDbContext.

Chcete-li získat úplnou kontrolu nad schématem databáze, děďte z jedné z dostupných IdentityDbContext tříd a nakonfigurujte kontext tak, aby zahrnoval Identity schéma voláním builder.ConfigurePersistedGrantContext(_operationalStoreOptions.Value) v metodě OnModelCreating.

Řadič konfigurace OIDC

Tato část se týká aplikace řešení Server .

V rámci OidcConfigurationController (Controllers/OidcConfigurationController.cs) je klientský koncový bod nastaven tak, aby zpracovával parametry OIDC.

Nastavení aplikace

Tato část se týká aplikace řešení Server .

V souboru nastavení aplikace (appsettings.json) v kořenovém adresáři IdentityServer projektu popisuje část seznam nakonfigurovaných klientů. V následujícím příkladu je jeden klient. Název klienta odpovídá názvu sestavení aplikace Client a podle konvence se mapuje na parametr OAuth ClientId. Profil označuje typ aplikace, který se konfiguruje. Profil se používá interně k ovlivňování konvencí, které zjednodušují proces konfigurace serveru.

"IdentityServer": {
  "Clients": {
    "{ASSEMBLY NAME}": {
      "Profile": "IdentityServerSPA"
    }
  }
}

Zástupný prvek {ASSEMBLY NAME} je název sestavení aplikace Client (například BlazorSample.Client).

Ověřovací balíček

Tato část se týká aplikace řešení Client .

Když je aplikace vytvořená tak, aby používala jednotlivé uživatelské účty (Individual), aplikace automaticky obdrží odkaz na Microsoft.AspNetCore.Components.WebAssembly.Authentication balíček. Balíček poskytuje sadu primitiv, které aplikaci pomáhají ověřovat uživatele a získávat tokeny pro volání chráněných rozhraní API.

Pokud do aplikace přidáváte ověřování, přidejte balíček Microsoft.AspNetCore.Components.WebAssembly.Authentication do aplikace ručně.

Poznámka:

Pokyny k přidávání balíčků do aplikací .NET najdete v článcích v části Instalace a správa balíčků na webu Pracovní postup používání balíčků (dokumentace k NuGetu). Ověřte správné verze balíčků na NuGet.org.

Konfigurace `HttpClient`

Tato část se týká aplikace řešení Client .

V souboru Program je nakonfigurován HttpClient k dodání instancí HttpClient, které zahrnují přístupové tokeny při provádění požadavků na server API. Při vytváření řešení je název HttpClient{PROJECT NAME}.ServerAPI, kde {PROJECT NAME} zástupný symbol je názvem projektu.

builder.Services.AddHttpClient("{PROJECT NAME}.ServerAPI", 
        client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
    .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("{PROJECT NAME}.ServerAPI"));

Zástupný {PROJECT NAME} symbol je název projektu při vytváření řešení. Například zadáním názvu BlazorSample projektu vznikne název HttpClient .BlazorSample.ServerAPI

Poznámka:

Pokud konfigurujete Blazor WebAssembly aplikaci tak, aby používala existující Identity instanci serveru, která není součástí hostovaného Blazor řešení, změňte HttpClient základní registraci adresy z IWebAssemblyHostEnvironment.BaseAddress (builder.HostEnvironment.BaseAddress) na adresu URL koncového bodu autorizace rozhraní API serverové aplikace.

Podpora autorizace rozhraní API

Tato část se týká aplikace řešení Client .

Podpora ověřování uživatelů je zapojena do kontejneru služby metodou rozšíření poskytovanou uvnitř Microsoft.AspNetCore.Components.WebAssembly.Authentication balíčku. Tato metoda nastaví služby vyžadované aplikací pro interakci s existujícím systémem autorizace.

builder.Services.AddApiAuthorization();

Konfigurace aplikace se načte konvencí z _configuration/{client-id}. Podle konvence je ID klienta nastavené na název sestavení aplikace. Tuto adresu URL je možné změnit tak, aby odkazovala na samostatný koncový bod voláním přetížené verze s možnostmi.

Soubor `Imports`

Tato část se týká aplikace řešení Client .

Jmenný prostor Microsoft.AspNetCore.Components.Authorization je dostupný v celé aplikaci prostřednictvím _Imports.razor souboru.

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}
@using {APPLICATION ASSEMBLY}.Shared

`Index` stránka

Tato část se týká aplikace řešení Client .

Stránka Index (wwwroot/index.html) obsahuje skript, který definuje v JavaScriptu AuthenticationService . AuthenticationService zpracovává podrobnosti nízké úrovně protokolu OIDC. Aplikace interně volá metody definované ve skriptu k provádění ověřovacích operací.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>

`App` komponenta

Tato část se týká aplikace řešení Client .

Komponenta App (App.razor) se podobá komponentě App nalezené v Blazor Server aplikacích:

Komponenta CascadingAuthenticationState spravuje zpřístupnění AuthenticationState zbytku aplikace.
Komponenta AuthorizeRouteView zajišťuje, že aktuální uživatel má oprávnění pro přístup k dané stránce, nebo jinak vykresluje komponentu RedirectToLogin.
Komponenta RedirectToLogin spravuje přesměrování neoprávněných uživatelů na přihlašovací stránku.

V důsledku změn v rozhraní napříč verzemi ASP.NET Core se v této části nezobrazuje označení komponenty App (App.razor). Pokud chcete zkontrolovat kód komponenty pro danou verzi, použijte některý z následujících přístupů:

Vytvořte aplikaci zřízenou pro ověřování z výchozí Blazor WebAssembly šablony projektu pro verzi ASP.NET Core, kterou chcete použít. Zkontrolujte komponentu App (App.razor) ve vygenerované aplikaci.
Zkontrolujte komponentu (App) v referenčním App.razor zdroji. Vyberte verzi ze selektoru větve a vyhledejte komponentu ve ProjectTemplates složce úložiště, protože App umístění komponenty se v průběhu let změnilo.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepínání větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

`RedirectToLogin` komponenta

Tato část se týká aplikace řešení Client .

Komponenta RedirectToLogin (RedirectToLogin.razor):

Spravuje přesměrování neoprávněných uživatelů na přihlašovací stránku.
Aktuální adresa URL, ke které se uživatel pokouší získat přístup, je udržována tak, aby se v případě úspěšného ověření vrátila na tuto stránku:
- Stav historie navigace v ASP.NET Core v .NET 7 nebo novějším
- Řetězec dotazu v ASP.NET Core v .NET 6 nebo starší.

Zkontrolujte komponentu v referenčním RedirectToLogin zdroji. Umístění komponenty se v průběhu času změnilo, proto k vyhledání komponenty použijte vyhledávací nástroje GitHubu.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

`LoginDisplay` komponenta

Tato část se týká aplikace řešení Client .

Komponenta LoginDisplay (LoginDisplay.razor) je vykreslena v komponentě MainLayout (MainLayout.razor) a spravuje následující chování:

Pro ověřené uživatele:
- Zobrazí aktuální uživatelské jméno.
- Nabízí odkaz na stránku profilu uživatele v ASP.NET Core Identity.
- Nabízí tlačítko pro odhlášení z aplikace.
Anonymní uživatelé:
- Nabízí možnost registrace.
- Nabízí možnost přihlášení.

Vzhledem ke změnám v rámci jednotlivých verzí ASP.NET Core se v této části nezobrazuje značkování komponenty LoginDisplayRazor. Pokud chcete zkontrolovat kód komponenty pro danou verzi, použijte některý z následujících přístupů:

Vytvořte aplikaci zřízenou pro ověřování z výchozí Blazor WebAssembly šablony projektu pro verzi ASP.NET Core, kterou chcete použít. Zkontrolujte komponentu LoginDisplay ve vygenerované aplikaci.
Zkontrolujte komponentu v referenčním LoginDisplay zdroji. Umístění komponenty se v průběhu času změnilo, proto k vyhledání komponenty použijte vyhledávací nástroje GitHubu. Použit je šablonovaný obsah pro Hosted, který se rovná true.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

`Authentication` komponenta

Tato část se týká aplikace řešení Client .

Stránka vytvořená komponentou Authentication (Pages/Authentication.razor) definuje trasy potřebné pro zpracování různých fází ověřování.

Komponenta RemoteAuthenticatorView :

Poskytuje balíček Microsoft.AspNetCore.Components.WebAssembly.Authentication.
Spravuje provádění příslušných akcí v každé fázi ověřování.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

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

Poznámka:

Referenční typy s možnou hodnotou null (NRT) a statická analýza null-stavu kompilátoru .NET jsou podporovány v ASP.NET Core ve verzích .NET 6 nebo novějších. Před vydáním ASP.NET Core, v .NET 6, se typ string objevuje bez označení typu null (?).

`FetchData` komponenta

Tato část se týká aplikace řešení Client .

Komponenta FetchData ukazuje, jak:

Zřízení přístupového tokenu
Použijte přístupový token ke volání chráněného rozhraní API prostředků v aplikaci Server.

Direktiva @attribute [Authorize]Blazor WebAssembly označuje autorizační systém, že uživatel musí být autorizovaný, aby mohl tuto komponentu navštívit. Přítomnost atributu Client v aplikaci nezabrání volání rozhraní API na serveru bez správných přihlašovacích údajů. Aplikace Server musí také používat [Authorize] na příslušných koncových bodech, aby je správně chránila.

IAccessTokenProvider.RequestAccessToken postará se o vyžádání přístupového tokenu, který je možné přidat do požadavku pro volání rozhraní API. Pokud je token uložený v mezipaměti nebo služba dokáže zřídit nový přístupový token bez zásahu uživatele, žádost o token proběhne úspěšně. V opačném případě požadavek tokenu selže s chybou AccessTokenNotAvailableException, která je zachycena try-catch v příkazu.

Aby bylo možné získat skutečný token, který se má zahrnout do požadavku, musí aplikace zkontrolovat, že požadavek byl úspěšný voláním tokenResult.TryGetToken(out var token).

Pokud byl požadavek úspěšný, proměnná tokenu se naplní přístupovým tokenem. Vlastnost tokenu AccessToken.Value zveřejňuje doslovný řetězec, který se má zahrnout do hlavičky požadavku Authorization.

Pokud se token nepodařilo zřídit bez zásahu uživatele, což vede k neúspěšné žádosti:

ASP.NET Core v .NET 7 nebo novějším: Aplikace naviguje na AccessTokenResult.InteractiveRequestUrl pomocí daného AccessTokenResult.InteractionOptions k umožnění aktualizace přístupového tokenu.
ASP.NET Core v .NET 6 nebo starší: Výsledek tokenu obsahuje adresu URL přesměrování. Přechod na tuto adresu URL přenese uživatele na přihlašovací stránku a po úspěšném ověření se vrátí na aktuální stránku.

@page "/fetchdata"
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using {APP NAMESPACE}.Shared
@attribute [Authorize]
@inject HttpClient Http

...

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        try
        {
            forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
        }
        catch (AccessTokenNotAvailableException exception)
        {
            exception.Redirect();
        }
    }
}

Aplikace Azure Service v Linuxu

Explicitně zadejte vystavitele při nasazování do služby Azure App Service na Linuxu. Další informace najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA.

Název a prohlášení role s API autorizací

Vlastní generátor uživatelů

Client V aplikaci vytvořte vlastní objekt pro vytváření uživatelů. Identity Server odesílá několik rolí jako pole JSON v jednom role nároku. Jedna role se odešle jako řetězcová hodnota v rámci deklarace. Továrna vytvoří jednotlivý role nárok pro každou roli uživatele.

CustomUserFactory.cs:

using System.Security.Claims;
using System.Text.Json;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;

public class CustomUserFactory(IAccessTokenProviderAccessor accessor)
    : AccountClaimsPrincipalFactory<RemoteUserAccount>(accessor)
{
    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(
        RemoteUserAccount account,
        RemoteAuthenticationUserOptions options)
    {
        var user = await base.CreateUserAsync(account, options);

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            var identity = (ClaimsIdentity)user.Identity;
            var roleClaims = identity.FindAll(identity.RoleClaimType).ToArray();

            if (roleClaims.Any())
            {
                foreach (var existingClaim in roleClaims)
                {
                    identity.RemoveClaim(existingClaim);
                }

                var rolesElem = 
                    account.AdditionalProperties[identity.RoleClaimType];

                if (options.RoleClaim is not null && rolesElem is JsonElement roles)
                {
                    if (roles.ValueKind == JsonValueKind.Array)
                    {
                        foreach (var role in roles.EnumerateArray())
                        {
                            var roleValue = role.GetString();

                            if (!string.IsNullOrEmpty(roleValue))
                            {
                                identity.AddClaim(
                                  new Claim(options.RoleClaim, roleValue));
                            }
        
                        }
                    }
                    else
                    {
                        var roleValue = roles.GetString();

                        if (!string.IsNullOrEmpty(roleValue))
                        {
                            identity.AddClaim(
                              new Claim(options.RoleClaim, roleValue));
                        }
                    }
                }
            }
        }

        return user;
    }
}

Client V aplikaci zaregistrujte továrnu Program v souboru:

builder.Services.AddApiAuthorization()
    .AddAccountClaimsPrincipalFactory<CustomUserFactory>();

Server V aplikaci zavolejte AddRolesIdentity tvůrce, který přidává služby související s rolemi.

V souboru Program:

using Microsoft.AspNetCore.Identity;

...

builder.Services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

V Startup.cs:

using Microsoft.AspNetCore.Identity;

...

services.AddDefaultIdentity<ApplicationUser>(options => 
    options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Konfigurace Identity serveru

Použijte jeden z následujících přístupů:

Možnosti autorizace rozhraní API
Profilová služba

Možnosti autorizace rozhraní API

Server V aplikaci:

Nakonfigurujte Identity server tak, aby vložil deklarace name a role do tokenu identity a přístupového tokenu.
Zabraňte výchozímu mapování rolí ve zpracovateli tokenu JWT.

V souboru Program:

using System.IdentityModel.Tokens.Jwt;

...

builder.Services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
        options.IdentityResources["openid"].UserClaims.Add("name");
        options.ApiResources.Single().UserClaims.Add("name");
        options.IdentityResources["openid"].UserClaims.Add("role");
        options.ApiResources.Single().UserClaims.Add("role");
    });

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

V Startup.cs:

using System.IdentityModel.Tokens.Jwt;
using System.Linq;

...

services.AddIdentityServer()
    .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
        options.IdentityResources["openid"].UserClaims.Add("name");
        options.ApiResources.Single().UserClaims.Add("name");
        options.IdentityResources["openid"].UserClaims.Add("role");
        options.ApiResources.Single().UserClaims.Add("role");
    });

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Profilová služba

Server V aplikaci vytvořte implementaciProfileService.

ProfileService.cs:

using IdentityModel;
using Duende.IdentityServer.Models;
using Duende.IdentityServer.Services;

public class ProfileService : IProfileService
{
    public ProfileService()
    {
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        var nameClaim = context.Subject.FindAll(JwtClaimTypes.Name);
        context.IssuedClaims.AddRange(nameClaim);

        var roleClaims = context.Subject.FindAll(JwtClaimTypes.Role);
        context.IssuedClaims.AddRange(roleClaims);

        await Task.CompletedTask;
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        await Task.CompletedTask;
    }
}

Server V aplikaci zaregistrujte službu profilu v Program souboru:

using Duende.IdentityServer.Services;

...

builder.Services.AddTransient<IProfileService, ProfileService>();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

V aplikaci Server zaregistrujte profilovou službu v Startup.ConfigureServicesStartup.cs.

using IdentityServer4.Services;

...

services.AddTransient<IProfileService, ProfileService>();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

Použití autorizačních mechanismů

Client V aplikaci jsou přístupy k autorizaci komponent v tuto chvíli funkční. Jakýkoli z mechanismů autorizace v komponentách může použít roli k autorizaci uživatele:

AuthorizeView component (příklad: <AuthorizeView Roles="Admin">)
[Authorize] direktiva atribuce (AuthorizeAttributepříklad: @attribute [Authorize(Roles = "Admin")])
Procedurální logika (příklad: if (user.IsInRole("Admin")) { ... })

Podporuje se více testů rolí:
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
{
    ...
}
```

V aplikaci Client se vyplní User.Identity.Name uživatelským jménem, což je obvykle přihlašovací e-mailová adresa uživatele.

`UserManager` a `SignInManager`

Nastavte typ deklarace identity identifikátoru uživatele, když aplikace serveru vyžaduje:

UserManager<TUser> nebo SignInManager<TUser> v koncovém bodu rozhraní API.
IdentityUser podrobnosti, jako je jméno uživatele, e-mailová adresa nebo koncový čas uzamčení.

V Program.cs pro ASP.NET Core v .NET 6 nebo novějším:

using System.Security.Claims;

...

builder.Services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Ve Startup.ConfigureServices verzích ASP.NET Core starších než 6.0:

using System.Security.Claims;

...

services.Configure<IdentityOptions>(options => 
    options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);

Následující WeatherForecastController protokoluje UserName , kdy je metoda Get volána.

Poznámka:

Následující příklad používá:

obor názvů s oborem souborů, což je funkce C# 10 nebo novější (.NET 6 nebo novější).
primární konstruktor, což je funkce dostupná v C# 12 nebo novější (.NET 8 nebo novější).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.Logging;
using BlazorSample.Server.Models;
using BlazorSample.Shared;

namespace BlazorSample.Server.Controllers;

[Authorize]
[ApiController]
[Route("[controller]")]
public class WeatherForecastController(ILogger<WeatherForecastController> logger, 
        UserManager<ApplicationUser> userManager) : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", 
        "Balmy", "Hot", "Sweltering", "Scorching"
    };

    [HttpGet]
    public async Task<IEnumerable<WeatherForecast>> Get()
    {
        var rng = new Random();

        var user = await userManager.GetUserAsync(User);

        if (user != null)
        {
            logger.LogInformation("User.Identity.Name: {UserIdentityName}", user.UserName);
        }

        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = rng.Next(-20, 55),
            Summary = Summaries[rng.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

V předchozím příkladu:

Jmenný prostor projektu Server je BlazorSample.Server.
Prostor názvů projektu Shared je BlazorSample.Shared.

Hostování ve službě Aplikace Azure Service s vlastní doménou a certifikátem

Následující doprovodné materiály vysvětlují:

Postup nasazení hostované Blazor WebAssembly aplikace se serverem Identity do služby Aplikace Azure Service s vlastní doménou
Vytvoření a použití certifikátu TLS pro komunikaci protokolu HTTPS s prohlížeči I když se pokyny zaměřují na používání certifikátu s vlastní doménou, pokyny platí stejně pro použití výchozí domény Aplikace Azure s, například contoso.azurewebsites.net.

Pro tento scénář hostování nepoužívejte stejný certifikát pro klíč podepisování tokenů serveru Duende a pro zabezpečenou komunikaci HTTPS webu s prohlížeči.

Použití různých certifikátů pro tyto dva požadavky je dobrým postupem zabezpečení, protože izoluje privátní klíče pro každý účel.
Certifikáty TLS pro komunikaci s prohlížeči se spravují nezávisle, aniž by to ovlivnilo Identity podepisování tokenů serveru.
Když Azure Key Vault dodává certifikát aplikaci App Service pro vlastní vazbu domény, Identity server nemůže získat stejný certifikát ze služby Azure Key Vault pro podepisování tokenů. Přestože je možné nakonfigurovat Identity server tak, aby používal stejný certifikát TLS z fyzické cesty, umístění certifikátů zabezpečení do správy zdrojového kódu je špatný postup a ve většině scénářů byste se měli vyhnout.

V následujícím návodu se samopodepsaný certifikát vytvoří v Azure Key Vault výhradně pro podepisování serverového tokenu. Konfigurace Identity serveru používá certifikát trezoru klíčů prostřednictvím úložiště certifikátů aplikaceCurrentUser>My. Další certifikáty používané pro provoz HTTPS s vlastními doménami se vytvářejí a konfigurují odděleně od podpisového Identity certifikátu serveru.

Konfigurace aplikace, služby Aplikace Azure a služby Azure Key Vault pro hostování s vlastní doménou a HTTPS:

Vytvořte plán služby App Service s úrovní Basic B1 nebo vyšší. App Service vyžaduje Basic B1 nebo vyšší úroveň služby pro použití vlastních domén.
Vytvořte certifikát PFX pro zabezpečenou komunikaci prohlížeče (protokol HTTPS) webu s běžným názvem plně kvalifikovaného názvu domény (FQDN), který řídí vaše organizace (například www.contoso.com). Vytvořte certifikát pomocí:
- Klíčová použití
  - Ověření digitálního podpisu (digitalSignature)
  - Šifrování klíče (keyEncipherment)
- Rozšířené nebo vylepšené použití klíče
  - Ověřování klienta (1.3.6.1.5.5.7.3.2)
  - Ověřování serveru (1.3.6.1.5.5.7.3.1)
K vytvoření certifikátu použijte jeden z následujících přístupů nebo jakýkoli jiný vhodný nástroj nebo online službu:
Poznamenejte si heslo, které se použije později k importu certifikátu do služby Azure Key Vault.

Další informace o certifikátech služby Azure Key Vault najdete v tématu Azure Key Vault: Certifikáty.
Vytvořte novou službu Azure Key Vault nebo použijte existující trezor klíčů ve vašem předplatném Azure.
V oblasti Certifikáty trezoru klíčů naimportujte PFX certifikát lokality. Poznamenejte si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.
Ve službě Azure Key Vault vygenerujte nový samosignovaný certifikát pro Identity podepisování tokenů serveru. Dejte certifikátu název certifikátu a subjekt. Předmět je určen jako CN={COMMON NAME}, kde {COMMON NAME} zástupný symbol je běžný název certifikátu. Běžný název může být libovolný alfanumerický řetězec. Jedná se například CN=IdentityServerSigning o platný předmět certifikátu. V Zásady vydávání>Konfigurace rozšířených zásad použijte výchozí nastavení. Poznamenejte si kryptografický otisk certifikátu, který se použije v konfiguraci aplikace později.
Na webu Azure Portal přejděte na Aplikace Azure Service a vytvořte novou službu App Service s následující konfigurací:
- Publikování je nastaveno na Code.
- Zásobník modulu runtime nastavený na běhové prostředí aplikace.
- V případě SKU a velikosti ověřte, že je úroveň služby App Service Basic B1 nebo vyšší. App Service vyžaduje Basic B1 nebo vyšší úroveň služby pro použití vlastních domén.
Jakmile Azure vytvoří službu App Service, otevřete konfiguraci aplikace a přidejte nové nastavení aplikace určující kryptografické otisky certifikátu zaznamenané dříve. Klíč nastavení aplikace je WEBSITE_LOAD_CERTIFICATES. Kryptografické otisky certifikátu v hodnotě nastavení aplikace oddělte čárkou, jak ukazuje následující příklad:
- Klíč: WEBSITE_LOAD_CERTIFICATES
- Hodnota: 57443A552A46DB...D55E28D412B943565,29F43A772CB6AF...1D04F0C67F85FB0B1
Uložení nastavení aplikace na webu Azure Portal je dvoustupňový proces: Uložte WEBSITE_LOAD_CERTIFICATES nastavení klíč-hodnota a pak vyberte tlačítko Uložit v horní části okna.
Vyberte nastavení PROTOKOLU TLS/SSL aplikace. Vyberte certifikáty privátního klíče (.pfx). Použijte proces importu certifikátu služby Key Vault. Tento postup použijte dvakrát k importu certifikátu webu pro komunikaci HTTPS i podpisového certifikátu tokenu serveru podepsaného svým držitelem Identity .
Přejděte do okna Vlastní domény . Na webu doménového registrátora nakonfigurujte doménu pomocí IP adresy a ID ověření vlastní domény. Typická konfigurace domény zahrnuje:
- Záznam typu A s hostitelem@ a hodnotou IP adresy z Azure portálu.
- TXT Record s hostitelemasuid a hodnotou ověřovacího ID vygenerovaného službou Azure a poskytnutého portálem Azure.
Ujistěte se, že změny uložíte na webu doménového registrátora správně. Některé weby registrátora vyžadují, aby se záznamy domény ukládaly dvěma kroky: Jeden nebo více záznamů se ukládá jednotlivě a pak aktualizuje registraci domény samostatným tlačítkem.
Vraťte se do okna Vlastní domény na webu Azure Portal. Vyberte Přidat vlastní doménu. Vyberte možnost A Záznam. Zadejte doménu a vyberte Ověřit. Pokud jsou záznamy domény správné a šíří se přes internet, portál umožňuje vybrat tlačítko Přidat vlastní doménu .

Může trvat několik dní, než se změny registrace domény rozšíří mezi internetové názvové servery domény (DNS) po jejich zpracování vaším doménovým registrátorem. Pokud se záznamy domény neaktualizují do tří pracovních dnů, ověřte, že jsou záznamy správně nastavené u doménového registrátora, a obraťte se na zákaznickou podporu.
V okně Vlastní domény je pro doménu uveden SSL STAV označený Not Secure. Vyberte odkaz Přidat vazbu. Vyberte certifikát HTTPS lokality z trezoru klíčů pro vazbu vlastní domény.
V sadě Visual Studio otevřete soubor nastavení aplikace projektu serveru (appsettings.json nebo appsettings.Production.json). Identity V konfiguraci serveru přidejte následující Key část. Zadejte předmět samopodepsaného certifikátu pro Name klíč. V následujícím příkladu je název obecných jmen certifikátu přiřazený v trezoru klíčů IdentityServerSigning, výsledkem bude PředmětCN=IdentityServerSigning:
```
"IdentityServer": {

  ...

  "Key": {
    "Type": "Store",
    "StoreName": "My",
    "StoreLocation": "CurrentUser",
    "Name": "CN=IdentityServerSigning"
  }
},
```
V sadě Visual Studio vytvořte profil publikování pro projekt Server služby Azure App Service. Na řádku nabídek vyberte: Build>Publikovat>Nová>Azure>Azure App Service (Windows nebo Linux). Když je Visual Studio připojené k předplatnému Azure, můžete nastavit zobrazení prostředků Azure podle typu prostředku. V seznamu webových aplikací vyhledejte App Service pro aplikaci a vyberte ji. Vyberte Dokončit.
Když se Visual Studio vrátí do okna Publikovat , automaticky se zjistí závislosti trezoru klíčů a databázové služby SQL Serveru.

Pro službu trezoru klíčů se nevyžadují žádné změny konfigurace výchozích nastavení.

Pro účely testování je možné nasadit místní databázi SQLite aplikace, která je nakonfigurovaná šablonou Blazor , s aplikací bez další konfigurace. Konfigurace jiné databáze pro Identity server v produkčním prostředí je nad rámec tohoto článku. Další informace najdete v databázových prostředcích v následujících sadách dokumentace:
- App Service
- Duende Identity Server
V horní části okna vyberte odkaz Upravit pod názvem profilu nasazení. Změňte cílovou adresu URL na adresu URL vlastní domény webu (například https://www.contoso.com). Uložte nastavení.
Umožňuje publikovat aplikaci. Visual Studio otevře okno prohlížeče a načte web na jeho vlastní doméně.

Dokumentace k Azure obsahuje další podrobnosti o používání služeb Azure a vlastních domén s vazbou TLS ve službě App Service, včetně informací o použití záznamů CNAME místo záznamů A. Další informace naleznete v následujících zdrojích:

Doporučujeme použít nové okno prohlížeče v privátním režimu (například režim InPrivate microsoft Edge nebo anonymní režim Google Chrome) pro každý testovací běh aplikace po změně aplikace, konfigurace aplikace nebo služeb Azure na webu Azure Portal. Zbývající cookies z předchozího testu mohou vést k selhání ověření nebo autorizace při testování webu, i když je konfigurace webu správná. Další informace o tom, jak nakonfigurovat Sadu Visual Studio tak, aby otevřela nové okno privátního prohlížeče pro každé testovací spuštění, najdete v části Soubory cookie a data webu.

Když se konfigurace služby App Service změní na webu Azure Portal, aktualizace se obecně projeví rychle, ale nejsou okamžité. Někdy musíte chvíli počkat, než se služba App Service restartuje, aby se změna konfigurace projevila.

Pokud řešíte potíže s načítáním Identity certifikátu pro podepisování klíčů serveru, spusťte v příkazovém prostředí PowerShellu Kudu na webu Azure Portal následující příkaz. Příkaz poskytuje seznam certifikátů, ke kterým má aplikace přístup z CurrentUser>My úložiště certifikátů. Výstup zahrnuje předměty certifikátů a kryptografické otisky užitečné při ladění aplikace:

Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Subject, Thumbprint, EnhancedKeyUsageList

Odstraňování potíží

Protokolování

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 v ASP.NET Core Blazor protokolování 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 daného scénáře může chybějící nebo nesprávná hodnota pro Authoritu, instanci, ID tenanta, doménu tenanta, ID klienta nebo identifikátor URI přesměrování zabránit aplikaci v ověření klientů.
- 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. Všimněte si, že port není nutný pro Microsoft Entra ID a aplikaci spuštěnou na adrese localhost pro testování vývoje, ale konfigurace portu aplikace a port, na kterém je aplikace spuštěná, se musí shodovat u ostatních adres než těch pro vývojové testování localhost.
V konfiguračních sekcích doporučení tohoto článku najdete příklady správné konfigurace. Pečlivě zkontrolujte každou část článku, ve které hledáte chybnou konfiguraci aplikace a IP adresy.

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. Pokyny pro vývojářské nástroje najdete v následujících článcích.
  - Google Chrome (dokumentace Google)
  - Microsoft Edge
  - Mozilla Firefox (dokumentace k Mozilla)
- U verzí Blazor , ve kterých se používá webový token JSON (JWT), dekódujte obsah tokenu, který se používá k ověřování klienta nebo přístupu k webovému rozhraní API serveru, v závislosti na tom, kde k problému dochází. Další informace najdete v tématu Kontrola obsahu webového tokenu JSON (JWT).
Tým dokumentace reaguje na zpětnou vazbu a chyby v článcích (otevřete problém z části Zpětná vazba na této stránce), ale nemůže poskytnout produktovou podporu. 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í, které nejsou bezpečnostní, citlivé ani důvěrné, vytvořte 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 zpráva citlivá nebo důvěrná, nebo pokud popisuje potenciální chybu zabezpečení v produktu, kterou mohou kyberútočníci zneužít, přečtěte si Hlášení problémů se zabezpečením a chyb (dotnet/aspnetcore úložiště GitHub).
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.

Soubory cookie a data webu

Soubory cookie a data webu se můžou uchovávat 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í:

Soubory cookie přihlašování uživatelů
Soubory cookie aplikace
Data lokality v mezipaměti a uložená data

Jedním z přístupů k tomu, aby se zabránilo zasahování souborů cookie a dat webu do testování a řešení potíží, 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ý buď ručně, nebo prostřednictvím integrovaného vývojového prostředí (IDE) pro jakoukoli změnu 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:
- Z dialogového okna Procházet otevřete dialogové okno z Visual Studio tlačítka Spustit.
- 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ý znak {URL} je odkaz, který chcete otevřít (například https://localhost:5001).
  - Mozilla Firefox: Použijte -private -url {URL}, kde je zástupný symbol {URL} URL adresou, která má být otevřena (například https://localhost:5001).
- Do pole Uživatelsky přívětivý 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řelo prohlížeč při jakékoli změně v aplikaci, testovacím uživateli nebo konfiguraci 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ů:

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í.
Odstraňte složky projektu bin a obj.
Obnovte a znovu sestavte projekt.
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. Pro informace o balíčku použijte NuGet Gallery nebo FuGet Package Explorer.

`Server` Spuštění aplikace

Při testování a řešení potíží s hostovaným Blazor WebAssemblyřešením se ujistěte, že aplikaci spouštíte z Server projektu.

Kontrola uživatele

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

User.razor:

@page "/user"
@attribute [Authorize]
@using System.Text.Json
@using System.Security.Claims
@inject IAccessTokenProvider AuthorizationService

<h1>@AuthenticatedUser?.Identity?.Name</h1>

<h2>Claims</h2>

@foreach (var claim in AuthenticatedUser?.Claims ?? Array.Empty<Claim>())
{
    <p class="claim">@(claim.Type): @claim.Value</p>
}

<h2>Access token</h2>

<p id="access-token">@AccessToken?.Value</p>

<h2>Access token claims</h2>

@foreach (var claim in GetAccessTokenClaims())
{
    <p>@(claim.Key): @claim.Value.ToString()</p>
}

@if (AccessToken != null)
{
    <h2>Access token expires</h2>

    <p>Current time: <span id="current-time">@DateTimeOffset.Now</span></p>
    <p id="access-token-expires">@AccessToken.Expires</p>

    <h2>Access token granted scopes (as reported by the API)</h2>

    @foreach (var scope in AccessToken.GrantedScopes)
    {
        <p>Scope: @scope</p>
    }
}

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

    public ClaimsPrincipal AuthenticatedUser { get; set; }
    public AccessToken AccessToken { get; set; }

    protected override async Task OnInitializedAsync()
    {
        await base.OnInitializedAsync();
        var state = await AuthenticationState;
        var accessTokenResult = await AuthorizationService.RequestAccessToken();

        if (!accessTokenResult.TryGetToken(out var token))
        {
            throw new InvalidOperationException(
                "Failed to provision the access token.");
        }

        AccessToken = token;

        AuthenticatedUser = state.User;
    }

    protected IDictionary<string, object> GetAccessTokenClaims()
    {
        if (AccessToken == null)
        {
            return new Dictionary<string, object>();
        }

        // header.payload.signature
        var payload = AccessToken.Value.Split(".")[1];
        var base64Payload = payload.Replace('-', '+').Replace('_', '/')
            .PadRight(payload.Length + (4 - payload.Length % 4) % 4, '=');

        return JsonSerializer.Deserialize<IDictionary<string, object>>(
            Convert.FromBase64String(base64Payload));
    }
}

Kontrola obsahu webového tokenu JSON (JWT)

K dekódování webového tokenu JSON (JWT) použijte nástroj microsoftu jwt.ms . Hodnoty v uživatelském rozhraní nikdy neopustí prohlížeč.

Příklad kódovaného JWT (zkrácený pro zobrazení):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j ... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Příklad dekódování JWT nástrojem pro aplikaci, která se ověřuje v Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/11112222-bbbb-3333-cccc-4444dddd5555/v2.0/",
  "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "nonce": "bbbb0000-cccc-1111-dddd-2222eeee3333",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Další materiály

Nasazení do služby Aplikace Azure
Import certifikátu ze služby Key Vault (dokumentace k Azure)
Další scénáře zabezpečení ASP.NET Core Blazor WebAssembly
Neověřené nebo neoprávněné požadavky webového rozhraní API v aplikaci se zabezpečeným výchozím klientem
Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení: Obsahuje pokyny k:
- Použití middlewaru Forwarded Headers k zachování informací o schématu HTTPS napříč proxy servery a interními sítěmi
- Další scénáře a případy použití, včetně ruční konfigurace schématu, změn cesty požadavku pro správné směrování požadavků a předávání schématu požadavků pro Linux a reverzní proxy servery mimo IIS.
Duende Identity Server

Sdílet prostřednictvím

Zabezpečení hostované aplikace ASP.NET Core Blazor WebAssembly pomocí Identity serveru

Průvodce

Vytvoření Blazor aplikace

Spustit aplikaci

Části řešení

Server služby aplikace

Autorizace rozhraní API

Přidejte obslužnou rutinu ověřování pro rozhraní API, které spoluexistuje se serverem Identity

Kontroler předpovědi počasí

Kontext databáze aplikace

Řadič konfigurace OIDC

Nastavení aplikace

Ověřovací balíček

Konfigurace HttpClient

Podpora autorizace rozhraní API

Soubor Imports

Index stránka

App komponenta

RedirectToLogin komponenta

LoginDisplay komponenta

Authentication komponenta

FetchData komponenta

Aplikace Azure Service v Linuxu

Název a prohlášení role s API autorizací

Vlastní generátor uživatelů

Konfigurace Identity serveru

Možnosti autorizace rozhraní API

Profilová služba

Použití autorizačních mechanismů

UserManager a SignInManager

Hostování ve službě Aplikace Azure Service s vlastní doménou a certifikátem

Odstraňování potíží

Protokolování

Běžné chyby

Soubory cookie a data webu

Upgrady aplikací

Server Spuštění aplikace

Kontrola uživatele

Kontrola obsahu webového tokenu JSON (JWT)

Další materiály

Další materiály

Konfigurace `HttpClient`

Soubor `Imports`

`Index` stránka

`App` komponenta

`RedirectToLogin` komponenta

`LoginDisplay` komponenta

`Authentication` komponenta

`FetchData` komponenta

`UserManager` a `SignInManager`

`Server` Spuštění aplikace