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í. Aplikace eShopOnContainers pro více platforem provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer 4. 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 eShopOnContainers 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 4

IdentityServer 4 je opensourcová architektura OpenID Připojení 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 identity ASP.NET Core Identity.

Poznámka:

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

OpenID Připojení 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 Připojení a OAuth 2.0 kombinují dvě základní aspekty zabezpečení přístupu k ověřování a rozhraní API a IdentityServer 4 je implementace těchto protokolů.

V aplikacích, které používají přímou komunikaci mezi klientem a mikroslužbou, jako je referenční aplikace eShopOnContainers, se k ověřování uživatelů dá použít vyhrazená ověřovací mikroslužba 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.

Aplikace eShopOnContainers pro více platforem komunikuje s mikroslužbou identity, která k ověřování používá IdentityServer 4, 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 4, 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, je nutné ho přidat do kanálu zpracování požadavků HTTP, aby bylo možné obsluhovat požadavky na koncové body OpenID Připojení a OAuth 2.0. Toho dosáhnete v Configure metodě ve třídě webové aplikace Startup , jak je znázorněno v následujícím příkladu kódu:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseIdentity();
}

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 by se měl nakonfigurovat v metodě ConfigureServices ve třídě Startup webové aplikace voláním services.AddIdentityServer metody, jak je znázorněno v následujícím příkladu kódu z referenční aplikace eShopOnContainers:

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddIdentityServer(x => x.IssuerUri = "null")
        .AddSigningCredential(Certificate.Get())
        .AddAspNetIdentity<ApplicationUser>()
        .AddConfigurationStore(builder =>
            builder.UseSqlServer(connectionString, options =>
                options.MigrationsAssembly(migrationsAssembly)))
        .AddOperationalStore(builder =>
            builder.UseSqlServer(connectionString, options =>
                options.MigrationsAssembly(migrationsAssembly)))
        .Services.AddTransient<IProfileService, ProfileService>();
}

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 IdentityServer 4. Rozhraní API IdentityServeru 4 umožňují konfiguraci IdentityServeru ze seznamu objektů konfigurace v paměti. V referenční aplikaci eShopOnContainers 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 eShopOnContainers:

public static IEnumerable<ApiResource> GetApis()
{
    return new List<ApiResource>
    {
        new ApiResource("orders", "Orders Service"),
        new ApiResource("basket", "Basket 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 dokumentaci k IdentityServeru 4 v prostředku rozhraní API .

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 eShopOnContainers:

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

Specifikace OpenID Připojení 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 Připojení (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 dokumentaci k IdentityServeru 4.

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 aplikaci eShopOnContainers s více platformami v GetClients metodě, která poskytuje tuto kolekci v referenční aplikaci eShopOnContainers:

public static IEnumerable<Client> GetClients(Dictionary<string,string> clientsUrl)
{
    return new List<Client>
    {
        // Omitted for brevity
        new Client
        {
            ClientId = "xamarin",
            ClientName = "eShop Xamarin OpenId Client",
            AllowedGrantTypes = GrantTypes.Hybrid,
            ClientSecrets =
            {
                new Secret("secret".Sha256())
            },
            RedirectUris = { clientsUrl["Xamarin"] },
            RequireConsent = false,
            RequirePkce = true,
            PostLogoutRedirectUris = { $"{clientsUrl["Xamarin"]}/Account/Redirecting" },
            AllowedCorsOrigins = { "http://eshopxamarin" },
            AllowedScopes = new List<string>
            {
                IdentityServerConstants.StandardScopes.OpenId,
                IdentityServerConstants.StandardScopes.Profile,
                IdentityServerConstants.StandardScopes.OfflineAccess,
                "orders",
                "basket"
            },
            AllowOfflineAccess = true,
            AllowAccessTokensViaBrowser = true
        },
    };
}

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.

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 Připojení 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 4.

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 eShopOnContainers se pro tento účel používá ASP.NET Základní identita.

Multiformní aplikace eShopOnContainers se ověřuje pomocí IdentityServeru pomocí toku hybridního ověřování, který je znázorněný na 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 eShopOnContainers 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 eShopOnContainers pro více platforem se komunikace s IdentityServer provádí IdentityService třídou, která implementuje IIdentityService rozhraní. Toto rozhraní určuje, že implementace třídy musí poskytovat CreateAuthorizationRequest, CreateLogoutRequesta GetTokenAsync metody.

Přihlášení

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

private async Task SignInAsync()
{
    await IsBusyFor(
        async () =>
        {
            LoginUrl = _identityService.CreateAuthorizationRequest();

            IsValid = true;
            IsLogin = true;
        });
}

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

public string CreateAuthorizationRequest()
{
    // Create URI to authorization endpoint
    var authorizeRequest = new AuthorizeRequest(GlobalSetting.Instance.IdentityEndpoint);
    // Dictionary with values for the authorize request
    var dic = new Dictionary<string, string>();
    dic.Add("client_id", GlobalSetting.Instance.ClientId);
    dic.Add("client_secret", GlobalSetting.Instance.ClientSecret); 
    dic.Add("response_type", "code id_token");
    dic.Add("scope", "openid profile basket orders locations marketing offline_access");
    dic.Add("redirect_uri", GlobalSetting.Instance.IdentityCallback);
    dic.Add("nonce", Guid.NewGuid().ToString("N"));
    dic.Add("code_challenge", CreateCodeChallenge());
    dic.Add("code_challenge_method", "S256");
    // Add CSRF token to protect against cross-site request forgery attacks.
    var currentCSRFToken = Guid.NewGuid().ToString("N");
    dic.Add("state", currentCSRFToken);
    
    var authorizeUri = authorizeRequest.Create(dic); 
    return authorizeUri;
}

Tato metoda vytvoří identifikátor 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 multiplatformní aplikace eShopOnContainers 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.

Vrácený identifikátor URI je uložen ve LoginUrl vlastnosti LoginViewModel třídy. Když se vlastnost změní na IsLogin hodnotu true, stane se WebView zviditelněná LoginView . Data WebView sváže svou Source vlastnost s LoginUrl vlastností LoginViewModel třídy a přihlašovací požadavek na IdentityServer, pokud LoginUrl je vlastnost nastavena na koncový bod autorizace IdentityServer. Když IdentityServer obdrží tento požadavek a uživatel není ověřený, WebView přesměruje se na nakonfigurovanou přihlašovací stránku zobrazenou na následujícím obrázku.

Po dokončení WebView přihlášení se přesměruje na vrácený identifikátor URI. Tato WebView navigace způsobí NavigateAsync spuštění metody ve LoginViewModel třídě, jak je znázorněno v následujícím příkladu kódu:

private async Task NavigateAsync(string url)
{
    var unescapedUrl = System.Net.WebUtility.UrlDecode(url);

    if (unescapedUrl.Equals(GlobalSetting.Instance.LogoutCallback, StringComparison.OrdinalIgnoreCase))
    {
        _settingsService.AuthAccessToken = string.Empty;
        _settingsService.AuthIdToken = string.Empty;
        IsLogin = false;
        LoginUrl = _identityService.CreateAuthorizationRequest();
    }
    else if (unescapedUrl.Contains(GlobalSetting.Instance.Callback, StringComparison.OrdinalIgnoreCase))
    {
        var authResponse = new AuthorizeResponse(url);
        if (!string.IsNullOrWhiteSpace(authResponse.Code))
        {
            var userToken = await _identityService.GetTokenAsync(authResponse.Code);
            string accessToken = userToken.AccessToken;

            if (!string.IsNullOrWhiteSpace(accessToken))
            {
                _settingsService.AuthAccessToken = accessToken;
                _settingsService.AuthIdToken = authResponse.IdentityToken;
                await NavigationService.NavigateToAsync("//Main/Catalog");
            }
        }
    }
}

Tato metoda parsuje odpověď ověřování obsaženou v návratovém identifikátoru URI a za předpokladu, že je k dispozici platný autorizační kód, vytvoří požadavek na koncový bod tokenu IdentityServeru, předání autorizačního kódu, ověření tajného kódu PKCE a další požadované parametry. Koncový bod tokenu je na /connect/token 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).

Tip

Nezapomeňte ověřit návratové identifikátory URI. I když multiformní aplikace eShopOnContainers neověřuje návratový identifikátor URI, osvědčeným postupem je ověřit, že návratový identifikátor URI odkazuje na známé umístění, aby se zabránilo útokům open-redirect.

Pokud koncový bod tokenu obdrží platný autorizační kód a ověřovací 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 eShopOnContainers je tedy tento: za předpokladu, že se uživatelé můžou úspěšně ověřit pomocí IdentityServeru, přejdou na trasu //Main/Catalog , což je TabbedPage to, že se zobrazí CatalogView jako vybraná karta.

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:

EShopOnContainers 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á LogoutParameter instanci nastavenou true jako parametr.

Když se vytvoří zobrazení a přejde na něj, InitializeAsync spustí se metoda přidruženého modelu zobrazení zobrazení, která pak spustí Logout metodu LoginViewModel třídy, která je znázorněna v následujícím příkladu kódu:

private void Logout()
{
    var authIdToken = Settings.AuthIdToken;
    var logoutRequest = _identityService.CreateLogoutRequest(authIdToken);

    if (!string.IsNullOrEmpty(logoutRequest))
    {
        // Logout
        LoginUrl = logoutRequest;
    }
    
    // Omitted for brevity
}

Tato metoda vyvolá metodu CreateLogoutRequestIdentityService ve třídě a předá token identity načtený z nastavení aplikace jako parametr. Další informace o nastavení aplikace naleznete v tématu Správa konfigurace. Následující příklad kódu ukazuje metodu CreateLogoutRequest :

public string CreateLogoutRequest(string token)
{
    // Omitted for brevity

    var (endpoint, callback) =
        (GlobalSetting.Instance.LogoutEndpoint, GlobalSetting.Instance.LogoutCallback);

    return $"{endpoint}?id_token_hint={token}&post_logout_redirect_uri={callback}";
}

Tato metoda vytvoří identifikátor URI koncového bodu relace IdentityServeru 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í.

Vrácený identifikátor URI je uložen ve LoginUrl vlastnosti LoginViewModel třídy. IsLogin Zatímco vlastnost je true, je zobrazena WebView v objektuLoginView. Data WebView sváže svou Source vlastnost s LoginUrl vlastností LoginViewModel třídy a vytvoří požadavek odhlášení na IdentityServer, pokud LoginUrl je vlastnost nastavena na koncový bod relace IdentityServer. K odhlášení dojde, když IdentityServer obdrží tento požadavek za předpokladu, že je uživatel přihlášený. Ověřování se sleduje pomocí souboru cookie spravovaného middlewarem ověřování souborů cookie z ASP.NET Core. Proto odhlášení z IdentityServer odebere ověřovací soubor cookie a odešle identifikátor URI přesměrování po odhlášení zpět klientovi.

Bude WebView přesměrován na identifikátor URI přesměrování po odhlášení v aplikaci pro více platforem. Tato WebView navigace způsobí NavigateAsync spuštění metody ve LoginViewModel třídě, která je znázorněna v následujícím příkladu kódu:

private async Task NavigateAsync(string url)
{
    var unescapedUrl = System.Net.WebUtility.UrlDecode(url);

    if (unescapedUrl.Equals(GlobalSetting.Instance.LogoutCallback, StringComparison.OrdinalIgnoreCase))
    {
        _settingsService.AuthAccessToken = string.Empty;
        _settingsService.AuthIdToken = string.Empty;
        IsLogin = false;
        LoginUrl = _identityService.CreateAuthorizationRequest();
    }
    
    // Omitted for brevity
}

Tato metoda vymaže token identity i přístupový token z nastavení aplikace. IsLogin Nastaví vlastnost na false, což způsobíWebView, že stránka LoginView bude neviditelná. LoginUrl Nakonec je vlastnost nastavena na identifikátor URI autorizačního koncového bodu IdentityServeru s požadovanými parametry při přípravě na další spuštění přihlášení uživatelem.

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:

EShopOnContainers také umožňuje napodobení odhlášení, 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, které poskytuje autorizaci řízení. Tento přístup je znázorněn v následujícím diagramu.

Multiformní aplikace eShopOnContainers 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 ConfigureAuth metody ve třídě webové aplikace Startup , která je vyvolána z Configure metody a je demonstrována v následujícím příkladu kódu z referenční aplikace eShopOnContainers:

protected virtual void ConfigureAuth(IApplicationBuilder app)
{
    var identityUrl = Configuration.GetValue<string>("IdentityUrl");
    app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
    {
        Authority = identityUrl.ToString(),
        ScopeName = "basket",
        RequireHttpsMetadata = false,
    });
}

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.

Poznámka:

Autorizační middleware IdentityServeru musí být přidán do kanálu požadavku HTTP webové aplikace před přidáním MVC s app.UseMvc() nebo app.UseMvcWithDefaultRoute().

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:

var authToken = Settings.AuthAccessToken;
Order = await _ordersService.GetOrderAsync(order.OrderNumber, authToken);

Přístupový token se uloží jako nastavení aplikace a načte se z úložiště specifického pro platformu a zahrne se do volání GetOrderAsync metody ve OrderService třídě.

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:

var authToken = Settings.AuthAccessToken;
await _basketService.UpdateBasketAsync(
    new CustomerBasket
    {
        BuyerId = userInfo.UserId, 
        Items = BasketItems.ToList()
    }, 
    authToken);

Přístupový token se načte z nastavení a zahrne se do volání UpdateBasketAsync metody ve BasketService třídě.

Třída RequestProvider v multiplatformní aplikaci eShopOnContainers používá HttpClient třídu k provádění požadavků na rozhraní RESTful API vystavená referenční aplikací eShopOnContainers. 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 DefaultRequestHeadersHttpClient 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 eShopOnContainers 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í. Aplikace eShopOnContainers pro více platforem provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer 4. IdentityServer je opensourcová architektura OpenID Připojení a OAuth 2.0 pro ASP.NET Core, která se integruje s ASP.NET identitou 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.