Ověřování a autorizace

Tip

Tento obsah je výňatek z elektronické knihy, vzory podnikových aplikací pomocí .NET MAUI, dostupné na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

Ověřování je proces získání identifikačních přihlašovacích údajů, jako je jméno a heslo od uživatele a ověření těchto přihlašovacích údajů vůči autoritě. Entita, která odeslala přihlašovací údaje, se považuje za ověřenou identitu, pokud jsou přihlašovací údaje platné. Po vytvoření identity proces autorizace určuje, jestli má tato identita přístup k danému prostředku.

Existuje mnoho přístupů k integraci ověřování a autorizace do aplikace .NET MAUI , která komunikuje s ASP.NET webovou aplikací, včetně použití ASP.NET Core Identity, externích zprostředkovatelů ověřování, jako jsou Microsoft, Google, Facebook nebo Twitter, a middleware pro ověřování. Multi-platformní aplikace eShop provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer. Aplikace požaduje tokeny zabezpečení z IdentityServer k ověření uživatele nebo přístupu k prostředku. Aby IdentityServer vydál tokeny jménem uživatele, musí se uživatel přihlásit k IdentityServeru. IdentityServer ale neposkytuje uživatelské rozhraní ani databázi pro ověřování. Proto v referenční aplikaci eShop se pro tento účel používá ASP.NET Základní identita.

Ověřování

Ověřování se vyžaduje, když aplikace potřebuje znát identitu aktuálního uživatele. ASP.NET primárním mechanismem core pro identifikaci uživatelů je systém členství ASP.NET Core Identity, který ukládá informace o uživatelích v úložišti dat nakonfigurovaných vývojářem. Toto úložiště dat bude obvykle úložištěm EntityFramework, ale vlastní úložiště nebo balíčky třetích stran se dají použít k ukládání informací o identitě ve službě Azure Storage, DocumentDB nebo jiných umístěních.

Pro scénáře ověřování, které používají místní úložiště dat uživatelů a uchovávají informace o identitě mezi požadavky prostřednictvím souborů cookie (jak je typické ve webových aplikacích ASP.NET), je ASP.NET Core Identity vhodným řešením. Soubory cookie však nejsou vždy přirozeným prostředkem pro zachování a přenos dat. Například webová aplikace ASP.NET Core, která zpřístupňuje koncové body RESTful, ke kterým se přistupuje z aplikace, bude obvykle muset použít ověřování nosného tokenu, protože v tomto scénáři se soubory cookie nedají použít. Nosné tokeny se ale dají snadno načíst a zahrnout do autorizační hlavičky webových požadavků provedených z aplikace.

Vydávání nosných tokenů pomocí IdentityServeru

IdentityServer je opensourcová architektura OpenID Connect a OAuth 2.0 pro ASP.NET Core, která se dá použít pro mnoho scénářů ověřování a autorizace, včetně vydávání tokenů zabezpečení pro místní uživatele ASP.NET Core Identity.

Poznámka:

OpenID Connect a OAuth 2.0 jsou velmi podobné a mají různé odpovědnosti.

OpenID Connect je ověřovací vrstva nad protokolem OAuth 2.0. OAuth 2 je protokol, který aplikacím umožňuje požadovat přístupové tokeny ze služby tokenů zabezpečení a používat je ke komunikaci s rozhraními API. Toto delegování snižuje složitost klientských aplikací i rozhraní API, protože ověřování a autorizace je možné centralizovat.

OpenID Connect a OAuth 2.0 kombinují dvě základní aspekty zabezpečení přístupu k ověřování a rozhraní API a IdentityServer je implementace těchto protokolů.

V aplikacích, které používají přímou komunikaci mezi klientem a mikroslužbou, jako je referenční aplikace eShopu, lze k ověřování uživatelů použít vyhrazenou ověřovací mikroslužbu fungující jako služba tokenů zabezpečení (STS), jak je znázorněno v následujícím diagramu. Další informace o přímé komunikaci mezi klientem a mikroslužbou najdete v tématu Mikroslužby.

Multiformní aplikace eShop komunikuje s mikroslužbou identity, která používá IdentityServer k ověřování a řízení přístupu pro rozhraní API. Z toho důvodu více platforem aplikace požaduje tokeny z IdentityServeru, a to buď pro ověřování uživatele, nebo pro přístup k prostředku:

• Ověřování uživatelů pomocí IdentityServer se dosahuje vícevrstevnou aplikací, která požaduje token identity , což představuje výsledek procesu ověřování. Minimálně obsahuje identifikátor uživatele a informace o tom, jak a kdy je uživatel ověřen. Může také obsahovat další data identity.
• Přístup k prostředku pomocí IdentityServer se dosahuje vícevrstvá aplikací požadující přístupový token, který umožňuje přístup k prostředku rozhraní API. Klienti požadují přístupové tokeny a předávají je do rozhraní API. Přístupové tokeny obsahují informace o klientovi a uživateli, pokud jsou k dispozici. Rozhraní API pak tyto informace používají k autorizaci přístupu k jejich datům.

Poznámka:

Aby mohl úspěšně požádat o tokeny, musí být klient zaregistrovaný u IdentityServeru. Další informace o přidávání klientů naleznete v tématu Definování klientů.

Přidání IdentityServeru do webové aplikace

Aby webová aplikace ASP.NET Core používala IdentityServer, musí být přidána do řešení sady Visual Studio webové aplikace. Další informace najdete v tématu Nastavení a přehled v dokumentaci k IdentityServeru. Jakmile je IdentityServer součástí řešení sady Visual Studio webové aplikace, musí se přidat do kanálu zpracování požadavků HTTP, aby bylo možné obsluhovat požadavky na koncové body OpenID Connect a OAuth 2.0. To je nakonfigurované v Identity.API Program.cs projektu, jak je znázorněno v následujícím příkladu kódu:

...

app.UseIdentityServer();

Pořadí záleží v kanálu zpracování požadavků HTTP webové aplikace. Proto musí být IdentityServer přidán do kanálu před architekturou uživatelského rozhraní, která implementuje přihlašovací obrazovku.

Konfigurace IdentityServeru

IdentityServer je nakonfigurovaný v Identity.API Program.cs projektu voláním AddIdentityServer metody, jak je znázorněno v následujícím příkladu kódu z referenční aplikace eShop:

builder.Services.AddIdentityServer(options =>
    {
        options.Authentication.CookieLifetime = TimeSpan.FromHours(2);
    
        options.Events.RaiseErrorEvents = true;
        options.Events.RaiseInformationEvents = true;
        options.Events.RaiseFailureEvents = true;
        options.Events.RaiseSuccessEvents = true;
    
        // TODO: Remove this line in production.
        options.KeyManagement.Enabled = false;
    })
    .AddInMemoryIdentityResources(Config.GetResources())
    .AddInMemoryApiScopes(Config.GetApiScopes())
    .AddInMemoryApiResources(Config.GetApis())
    .AddInMemoryClients(Config.GetClients(builder.Configuration))
    .AddAspNetIdentity<ApplicationUser>()
    // TODO: Not recommended for production - you need to store your key material somewhere secure
    .AddDeveloperSigningCredential();

Po volání services.AddIdentityServer metody se volají další rozhraní API fluent, která nakonfigurují následující:

• Přihlašovací údaje používané k podepisování.
• Prostředky rozhraní API a identity, ke kterým můžou uživatelé požádat o přístup.
• Klienti, kteří se budou připojovat k tokenům žádostí.
• ASP.NET základní identita.

Tip

Dynamicky načtěte konfiguraci IdentityServeru. Rozhraní API serveru IdentityServer umožňují konfiguraci IdentityServeru ze seznamu objektů konfigurace v paměti. V referenční aplikaci eShop jsou tyto kolekce v paměti pevně zakódovány do aplikace. V produkčních scénářích je ale možné je dynamicky načíst z konfiguračního souboru nebo z databáze.

Informace o konfiguraci IdentityServer pro použití ASP.NET Core Identity naleznete v tématu Použití ASP.NET základní identity v dokumentaci k IdentityServeru.

Konfigurace prostředků rozhraní API

Při konfiguraci prostředků rozhraní API metoda AddInMemoryApiResources očekává kolekci IEnumerable<ApiResource> . Následující příklad kódu ukazuje metodu GetApis , která poskytuje tuto kolekci v referenční aplikaci eShop:

public static IEnumerable<ApiResource> GetApis()
{
    return new List<ApiResource>
    {
        new ApiScope("orders", "Orders Service"),
        new ApiScope("basket", "Basket Service"),
        new ApiScope("webhooks", "Webhooks registration Service"),
    };
}

Tato metoda určuje, že IdentityServer by měl chránit objednávky a nákupní rozhraní API. Proto budou při volání těchto rozhraní API vyžadovány přístupové tokeny spravované serverem IdentityServer. Další informace o ApiResource typu najdete v tématu Prostředek rozhraní API v dokumentaci k IdentityServeru.

Konfigurace prostředků identit

Při konfiguraci prostředků identity metoda AddInMemoryIdentityResources očekává kolekci IEnumerable<IdentityResource> . Prostředky identity jsou data, jako je ID uživatele, jméno nebo e-mailová adresa. Každý prostředek identity má jedinečný název a k němu lze přiřadit libovolné typy deklarací identity, které budou zahrnuty do tokenu identity pro uživatele. Následující příklad kódu ukazuje metodu GetResources , která poskytuje tuto kolekci v referenční aplikaci eShop:

public static IEnumerable<IdentityResource> GetResources()
{
    return new List<IdentityResource>
    {
        new IdentityResources.OpenId(),
        new IdentityResources.Profile()
    };
}

Specifikace OpenID Connect určuje některé standardní prostředky identity. Minimálním požadavkem je, aby byla podpora poskytována pro generování jedinečného ID pro uživatele. Toho dosáhnete zveřejněním IdentityResources.OpenId prostředku identity.

Poznámka:

Třída IdentityResources podporuje všechny obory definované ve specifikaci OpenID Connect (openid, e-mail, profil, telefon a adresa).

IdentityServer také podporuje definování vlastních prostředků identit. Další informace najdete v tématu Definování vlastních prostředků identit v dokumentaci k IdentityServeru. Další informace o typu IdentityResource najdete v části Prostředek identity v dokumentaci k IdentityServeru.

Konfigurace klientů

Klienti jsou aplikace, které mohou požadovat tokeny z IdentityServeru. Obvykle musí být pro každého klienta definována následující nastavení minimálně:

• Jedinečné ID klienta.
• Povolené interakce se službou tokenů (označované jako typ udělení)
• Umístění, kam se odesílají identity a přístupové tokeny (označované jako identifikátor URI přesměrování).
• Seznam prostředků, ke kterým má klient povolený přístup (označovaný jako obory).

Při konfiguraci klientů metoda AddInMemoryClients očekává kolekci IEnumerable<Client> . Následující příklad kódu ukazuje konfiguraci pro multiformní aplikaci eShop v GetClients metodě, která poskytuje tuto kolekci v referenční aplikaci eShop:

public static IEnumerable<Client> GetClients(Dictionary<string,string> clientsUrl)
{
    return new List<Client>
    {
        // Omitted for brevity
        new Client
        {
            ClientId = "maui",
            ClientName = "eShop MAUI OpenId Client",
            AllowedGrantTypes = GrantTypes.Code,                    
            //Used to retrieve the access token on the back channel.
            ClientSecrets =
            {
                new Secret("secret".Sha256())
            },
            RedirectUris = { configuration["MauiCallback"] },
            RequireConsent = false,
            RequirePkce = true,
            PostLogoutRedirectUris = { $"{configuration["MauiCallback"]}/Account/Redirecting" },
            AllowedScopes = new List<string>
            {
                IdentityServerConstants.StandardScopes.OpenId,
                IdentityServerConstants.StandardScopes.Profile,
                IdentityServerConstants.StandardScopes.OfflineAccess,
                "orders",
                "basket",
                "mobileshoppingagg",
                "webhooks"
            },
            //Allow requesting refresh tokens for long lived API access
            AllowOfflineAccess = true,
            AllowAccessTokensViaBrowser = true,
            AlwaysIncludeUserClaimsInIdToken = true,
            AccessTokenLifetime = 60 * 60 * 2, // 2 hours
            IdentityTokenLifetime = 60 * 60 * 2 // 2 hours
        }
    };
}

Tato konfigurace určuje data pro následující vlastnosti:

Vlastnost	Popis
ClientId	Jedinečné ID klienta.
ClientName	Zobrazovaný název klienta, který se používá k protokolování a obrazovce souhlasu.
AllowedGrantTypes	Určuje, jak chce klient pracovat s IdentityServerem. Další informace najdete v tématu Konfigurace toku ověřování.
ClientSecrets	Určuje přihlašovací údaje tajného klíče klienta, které se použijí při vyžádání tokenů z koncového bodu tokenu.
RedirectUris	Určuje povolené identifikátory URI, kterým se mají vracet tokeny nebo autorizační kódy.
RequireConsent	Určuje, jestli se vyžaduje obrazovka pro vyjádření souhlasu.
RequirePkce	Určuje, jestli klienti používající autorizační kód musí odeslat ověřovací klíč.
PostLogoutRedirectUris	Určuje povolené identifikátory URI, na které se mají přesměrovat po odhlášení.
AllowedCorsOrigins	Určuje původ klienta, aby IdentityServer mohl povolit volání mezi zdroji z původu.
AllowedScopes	Určuje prostředky, ke které má klient přístup. Ve výchozím nastavení nemá klient přístup k žádným prostředkům.
AllowOfflineAccess	Určuje, jestli klient může požadovat obnovovací tokeny.
AllowAccessTokensViaBrowser	Určuje, jestli klient může přijímat přístupové tokeny z okna prohlížeče.
AlwaysIncludeUserClaimsInIdToken	Určuje, že deklarace identity uživatele budou vždy přidány do tokenu ID. Ve výchozím nastavení by se musely načíst pomocí koncového userinfo bodu.
AccessTokenLifetime	Určuje životnost přístupového tokenu v sekundách.
IdentityTokenLifetime	Určuje životnost tokenu identity v sekundách.

Konfigurace toku ověřování

Tok ověřování mezi klientem a IdentityServerem je možné nakonfigurovat zadáním typů udělení ve Client.AllowedGrantTypes vlastnosti. Specifikace OpenID Connect a OAuth 2.0 definují několik toků ověřování, mezi které patří:

Tok ověřování	Popis
Implicitní	Tento tok je optimalizovaný pro aplikace založené na prohlížeči a měl by se používat buď pro ověřování uživatelů, nebo pro žádosti o přístupový token a ověřování. Všechny tokeny se přenášejí přes prohlížeč, a proto pokročilé funkce, jako jsou obnovovací tokeny, nejsou povolené.
Autorizační kód	Tento tok poskytuje možnost načíst tokeny na zadním kanálu, nikoli na frontový kanál prohlížeče, a zároveň podporuje ověřování klientů.
Hybridní	Tento tok je kombinací implicitních a autorizačních typů udělení kódu. Token identity se přenáší prostřednictvím kanálu prohlížeče a obsahuje podepsanou odpověď protokolu a další artefakty, jako je autorizační kód. Po úspěšném ověření odpovědi by se k načtení přístupového a obnovovacího tokenu měl použít zpětný kanál.

Tip

Zvažte použití toku hybridního ověřování. Hybridní tok ověřování zmírní řadu útoků, které platí pro kanál prohlížeče, a je doporučeným tokem pro nativní aplikace, které chtějí načítat přístupové tokeny (a případně aktualizovat tokeny).

Další informace o tocích ověřování najdete v tématu Udělení typů v dokumentaci k IdentityServeru.

Provádění ověřování

Aby IdentityServer vydál tokeny jménem uživatele, musí se uživatel přihlásit k IdentityServeru. IdentityServer ale neposkytuje uživatelské rozhraní ani databázi pro ověřování. Proto v referenční aplikaci eShop se pro tento účel používá ASP.NET Základní identita.

Multiformní aplikace eShop se ověřuje pomocí IdentityServeru pomocí toku hybridního ověřování, který je znázorněný v následujícím diagramu.

Žádost o přihlášení se provede na <base endpoint>:5105/connect/authorize. Po úspěšném ověření vrátí IdentityServer odpověď na ověření obsahující autorizační kód a token identity. Autorizační kód se odešle do <base endpoint>:5105/connect/tokenodpovědi na přístup, identitu a obnovovací tokeny.

Multiformní aplikace eShop se odhlásí z IdentityServer odesláním požadavku s <base endpoint>:5105/connect/endsession dalšími parametry. Po odhlášení identityServer odpoví odesláním identifikátoru URI po odhlášení zpět do více platforem aplikace. Tento proces znázorňuje následující diagram.

V aplikaci pro více platforem eShop se komunikace s IdentityServer provádí IdentityService třídou, která implementuje IIdentityService rozhraní. Toto rozhraní určuje, že implementace třídy musí poskytovat SignInAsync, SignOutAsyncGetUserInfoAsync a GetAuthTokenAsync metody.

Přihlášení

Když uživatel klepne na tlačítko na LoginView, třída SignInCommand LoginViewModel se spustí, která následně spustí metoduSignInAsync.LOGIN Následující příklad kódu ukazuje tuto metodu:

[RelayCommand]
private async Task SignInAsync()
{
    await IsBusyFor(
        async () =>
        {
            var loginSuccess = await _appEnvironmentService.IdentityService.SignInAsync();

            if (loginSuccess)
            {
                await NavigationService.NavigateToAsync("//Main/Catalog");
            }
        });
}

Tato metoda vyvolá metodu SignInAsync IdentityService ve třídě, jak je znázorněno v následujícím příkladu kódu:

public async Task<bool> SignInAsync()
{
    var response = await GetClient().LoginAsync(new LoginRequest()).ConfigureAwait(false);

    if (response.IsError)
    {
        return false;
    }

    await _settingsService
        .SetUserTokenAsync(
            new UserToken
            {
                AccessToken = response.AccessToken,
                IdToken = response.IdentityToken,
                RefreshToken = response.RefreshToken,
                ExpiresAt = response.AccessTokenExpiration
            })
        .ConfigureAwait(false);

    return !response.IsError;
}

Využívá IdentityService poskytnutý OidcClient IdentityModel.OidcClient balíček NuGet. Tento klient zobrazí uživateli v aplikaci webové zobrazení ověřování a zachytí výsledek ověření. Klient se připojí k identifikátoru URI pro koncový bod autorizace IdentityServeru s požadovanými parametry. Koncový bod autorizace je na /connect/authorize portu 5105 základního koncového bodu vystaveného jako uživatelské nastavení. Další informace o uživatelských nastaveních najdete v tématu Správa konfigurace.

Poznámka:

Prostor pro útoky na víceplatformní aplikaci eShop je omezen implementací rozšíření PKCE (Proof Key for Code Exchange) do OAuth. PkCE chrání autorizační kód před tím, než se použije, pokud je zachycen. Toho dosáhne klient generující ověřovatel tajných kódů, hodnotu hash, která se předává v žádosti o autorizaci a která se zobrazí při uplatnění autorizačního kódu. Další informace o infrastruktuře PKCE naleznete v tématu Kontrola pravopisu pro výměnu kódu pomocí veřejných klientů OAuth na webu Internet Engineering Task Force.

Pokud koncový bod tokenu obdrží platné ověřovací informace, autorizační kód a ověřovatel tajných kódů PKCE, odpoví přístupovým tokenem, tokenem identity a obnovovacím tokenem. Přístupový token (který umožňuje přístup k prostředkům rozhraní API) a token identity se uloží jako nastavení aplikace a provede se navigace na stránce. Celkový účinek v aplikaci pro více platforem eShopu je proto tento: za předpokladu, že se uživatelé můžou úspěšně ověřit pomocí IdentityServeru, přejdou na //Main/Catalog trasu, což je TabbedPage trasa, která zobrazuje CatalogView jako vybranou kartu.

Informace o navigaci na stránce naleznete v části Navigace. Informace o tom, jak navigace WebView způsobí spuštění metody modelu zobrazení, naleznete v tématu Vyvolání navigace pomocí chování. Informace o nastavení aplikace naleznete v tématu Správa konfigurace.

Poznámka:

EShop také umožňuje napodobení přihlásit se, když je aplikace nakonfigurovaná tak, aby používala napodobené služby v aplikaci SettingsView. V tomto režimu aplikace nekomunikuje se serverem IdentityServer, ale umožňuje uživateli přihlásit se pomocí jakýchkoli přihlašovacích údajů.

Odhlášení

Když uživatel klepne na LOG OUT tlačítko v ProfileViewsadě , LogoutCommand spustí se třída ProfileViewModel , která spustí metodu LogoutAsync . Tato metoda provádí navigaci na LoginView stránce a předává Logout parametr dotazu nastavený na true.

Tento parametr se vyhodnocuje ApplyQueryAttributes v metodě. Logout Pokud je parametr přítomn s true hodnotou, PerformLogoutAsync spustí se metoda LoginViewModel třídy, která je znázorněna v následujícím příkladu kódu:

private async Task PerformLogoutAsync()
{
    await _appEnvironmentService.IdentityService.SignOutAsync();

    _settingsService.UseFakeLocation = false;

    UserName.Value = string.Empty;
    Password.Value = string.Empty;
}

Tato metoda vyvolá metodu SignOutAsync IdentityService ve třídě, která vyvolá OidcClient relaci koncového uživatele a vymaže všechny uložené tokeny uživatele. Další informace o nastavení aplikace naleznete v tématu Správa konfigurace. Následující příklad kódu ukazuje metodu SignOutAsync :

public async Task<bool> SignOutAsync()
{
    var response = await GetClient().LogoutAsync(new LogoutRequest()).ConfigureAwait(false);

    if (response.IsError)
    {
        return false;
    }

    await _settingsService.SetUserTokenAsync(default);

    return !response.IsError;
}

Tato metoda používá k volání identifikátoru OidcClient URI koncovému koncovému bodu relace IdentityServer s požadovanými parametry. Koncový bod koncové relace je na /connect/endsession portu 5105 základního koncového bodu vystaveného jako uživatelské nastavení. Jakmile se uživatel úspěšně odhlásí, LoginView zobrazí se uživateli a všechny uložené informace o uživateli se vymažou.

Informace o navigaci na stránce naleznete v části Navigace. Informace o tom, jak WebView navigace způsobí spuštění metody modelu zobrazení, naleznete v tématu Vyvolání navigace pomocí chování. Informace o nastavení aplikace naleznete v tématu Správa konfigurace.

Poznámka:

EShop také umožňuje napodobení odhlásit se, když je aplikace nakonfigurovaná tak, aby používala napodobené služby v aplikaci SettingsView. V tomto režimu aplikace nekomunikuje s IdentityServerem a místo toho vymaže všechny uložené tokeny z nastavení aplikace.

Autorizace

Po ověření potřebují ASP.NET webová rozhraní API core často autorizovat přístup, což službě umožňuje zpřístupnit rozhraní API některým ověřeným uživatelům, ale ne všem.

Omezení přístupu k trase ASP.NET Core lze dosáhnout použitím atributu Authorize na kontroler nebo akci, která omezuje přístup k kontroleru nebo akci ověřeným uživatelům, jak je znázorněno v následujícím příkladu kódu:

[Authorize]
public sealed class BasketController : Controller
{
    // Omitted for brevity
}

Pokud se neoprávněný uživatel pokusí o přístup k kontroleru nebo akci označené atributem Autorizovat, rozhraní API vrátí stavový 401 (unauthorized) kód HTTP.

Poznámka:

U atributu Authorize je možné zadat parametry, které omezí rozhraní API na konkrétní uživatele. Další informace najdete v tématu ASP.NET Core Docs: Autorizace.

IdentityServer je možné integrovat do pracovního postupu autorizace, aby přístupové tokeny poskytovaly autorizaci řízení. Tento přístup je znázorněn v následujícím diagramu.

Multiformní aplikace eShop komunikuje s mikroslužbou identity a v rámci procesu ověřování požaduje přístupový token. Přístupový token se pak předá rozhraním API vystaveným objednávkou a košíkovými mikroslužbami v rámci žádostí o přístup. Přístupové tokeny obsahují informace o klientovi a uživateli. Rozhraní API pak tyto informace používají k autorizaci přístupu k jejich datům. Informace o tom, jak nakonfigurovat IdentityServer pro ochranu rozhraní API, najdete v tématu Konfigurace prostředků rozhraní API.

Konfigurace IdentityServer pro provedení autorizace

Aby bylo možné provést autorizaci pomocí IdentityServer, musí být do kanálu požadavku HTTP webové aplikace přidán autorizační middleware. Middleware se přidá do AddDefaultAuthentication rozšiřující metody, která je vyvolána z AddApplicationServices metody ve Program třídě a je demonstrována v následujícím příkladu kódu z referenční aplikace eShop:

public static IServiceCollection AddDefaultAuthentication(this IHostApplicationBuilder builder)
{
    var services = builder.Services;
    var configuration = builder.Configuration;

    var identitySection = configuration.GetSection("Identity");

    if (!identitySection.Exists())
    {
        // No identity section, so no authentication
        return services;
    }

    // prevent from mapping "sub" claim to nameidentifier.
    JsonWebTokenHandler.DefaultInboundClaimTypeMap.Remove("sub");

    services.AddAuthentication().AddJwtBearer(options =>
    {
        var identityUrl = identitySection.GetRequiredValue("Url");
        var audience = identitySection.GetRequiredValue("Audience");

        options.Authority = identityUrl;
        options.RequireHttpsMetadata = false;
        options.Audience = audience;
        options.TokenValidationParameters.ValidIssuers = [identityUrl];
        options.TokenValidationParameters.ValidateAudience = false;
    });

    services.AddAuthorization();

    return services;
}

Tato metoda zajišťuje přístup k rozhraní API pouze pomocí platného přístupového tokenu. Middleware ověří příchozí token, aby se zajistilo, že je odeslán od důvěryhodného vystavitele, a ověří, že token je platný pro použití s rozhraním API, které ho obdrží. Proto přechod na kontroler objednávek nebo košíku vrátí stavový 401 (unauthorized) kód HTTP, který indikuje, že je vyžadován přístupový token.

Vytváření žádostí o přístup k rozhraním API

Při provádění požadavků na mikroslužby objednávání a košíku musí být přístupový token získaný z IdentityServer součástí požadavku, jak je znázorněno v následujícím příkladu kódu:

public async Task CreateOrderAsync(Models.Orders.Order newOrder)
{
    var authToken = await _identityService.GetAuthTokenAsync().ConfigureAwait(false);

    if (string.IsNullOrEmpty(authToken))
    {
        return;
    }

    var uri = $"{UriHelper.CombineUri(_settingsService.GatewayOrdersEndpointBase, ApiUrlBase)}?api-version=1.0";

    var success = await _requestProvider.PostAsync(uri, newOrder, authToken, "x-requestid").ConfigureAwait(false);
}

Přístupový token je uložen s implementací IIdentityService a lze jej GetAuthTokenAsync načíst pomocí metody.

Podobně musí být přístupový token zahrnutý při odesílání dat do rozhraní API chráněného identityServerem, jak je znázorněno v následujícím příkladu kódu:

public async Task ClearBasketAsync()
{
    var authToken = await _identityService.GetAuthTokenAsync().ConfigureAwait(false);

    if (string.IsNullOrEmpty(authToken))
    {
        return;
    }

    await GetBasketClient().DeleteBasketAsync(new DeleteBasketRequest(), CreateAuthenticationHeaders(authToken))
        .ConfigureAwait(false);
}

Přístupový token se načte z IIdentityService volání metody ve třídě a je zahrnutý do volání ClearBasketAsync metody.BasketService

Třída RequestProvider v aplikaci pro více platforem eShop používá HttpClient třídu k provádění požadavků na rozhraní RESTful API vystavená referenční aplikací eShop. Při provádění požadavků na rozhraní API objednávek a košíků, která vyžadují autorizaci, musí být do požadavku zahrnut platný přístupový token. Toho dosáhnete přidáním přístupového tokenu do hlaviček instance HttpClient, jak je znázorněno v následujícím příkladu kódu:

httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);

Vlastnost DefaultRequestHeaders HttpClient třídy zveřejňuje hlavičky, které se odesílají s každou žádostí, a přístupový token se přidá do Authorization hlavičky s předponou řetězce Bearer. Když se požadavek odešle do rozhraní RESTful API, hodnota Authorization hlavičky se extrahuje a ověří, aby se zajistilo, že se odešle od důvěryhodného vystavitele a použije se k určení, jestli má uživatel oprávnění k vyvolání rozhraní API, které ho obdrží.

Další informace o tom, jak aplikace eShop pro více platforem vytváří webové žádosti, najdete v tématu Přístup ke vzdáleným datům.

Shrnutí

Existuje mnoho přístupů k integraci ověřování a autorizace do aplikace .NET MAUI , která komunikuje s ASP.NET webovou aplikací. Multi-platformní aplikace eShop provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer. IdentityServer je opensourcová architektura OpenID Connect a OAuth 2.0 pro ASP.NET Core, která se integruje s identitou ASP.NET Core za účelem ověřování nosných tokenů.

Více platforem aplikace požaduje tokeny zabezpečení z IdentityServer k ověření uživatele nebo přístupu k prostředku. Při přístupu k prostředku musí být přístupový token součástí požadavku na rozhraní API, která vyžadují autorizaci. Middleware IdentityServer ověřuje příchozí přístupové tokeny, aby se zajistilo, že se odesílají od důvěryhodného vystavitele a že jsou platné pro použití s rozhraním API, které je přijme.