Ověřování a autorizace
Poznámka:
Tato elektronická kniha byla publikována na jaře roku 2017 a od té doby nebyla aktualizována. Existuje mnoho v knize, která zůstává cenná, ale některé materiály jsou zastaralé.
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ě. Pokud jsou přihlašovací údaje platné, považuje se entita, která přihlašovací údaje odeslala, za ověřenou identitu. Po ověř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 Xamarin.Forms aplikace, která komunikuje s webovou aplikací ASP.NET MVC, 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í. Mobilní aplikace eShopOnContainers provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer 4. Mobilní aplikace požaduje tokeny zabezpečení z IdentityServeru, a to buď pro ověřování uživatele, nebo pro přístup 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, Azure Cosmos DB nebo jiných umístěních.
Scénáře ověřování, které využívají místní úložiště uživatelských dat a které uchovávají informace o identitě mezi požadavky prostřednictvím souborů cookie (jak je typické ve webových aplikacích ASP.NET MVC), 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 mobilní aplikace, obvykle potřebuje použít ověřování nosného tokenu, protože v tomto scénáři se soubory cookie nedají použít. Nosné tokeny je však možné snadno načíst a zahrnout do autorizační hlavičky webových požadavků provedených z mobilní aplikace.
Vydávání nosných tokenů pomocí IdentityServeru 4
IdentityServer 4 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 identity ASP.NET Core.
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.
Kombinace OpenID Connect a OAuth 2.0 kombinuje 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, je možné 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 na obrázku 9-1. Další informace o přímé komunikaci mezi klientem a mikroslužbou naleznete v tématu Komunikace mezi klientem a mikroslužbami.
Obrázek 9–1: Ověřování pomocí vyhrazené mikroslužby ověřování
Mobilní aplikace eShopOnContainers komunikuje s mikroslužbou identity, která k ověřování používá IdentityServer 4 a řízení přístupu pro rozhraní API. Mobilní aplikace proto 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 mobilní 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 se uživatel ověřil. Může také obsahovat další data identity.
- Přístup k prostředku pomocí IdentityServer se dosahuje mobilní 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živatel (pokud je k dispozici). Rozhraní API pak tyto informace používají k autorizaci přístupu k jejich datům.
Poznámka:
Aby mohl požádat o tokeny, musí být klient zaregistrovaný u IdentityServeru.
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 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 webové aplikace, aby mohl obsluhovat požadavky na koncové body OpenID Connect 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 měl být nakonfigurován v ConfigureServices metodě ve třídě webové aplikace Startup 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 spravované přístupové tokeny 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é se pak zahrnou 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 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 o IdentityResource typu najdete v dokumentaci k IdentityServeru 4 v části Prostředek identity.
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 mobilní aplikace eShopOnContainers 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>
{
...
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:
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 naleznete v tématu Konfigurace toku ověřování.ClientSecrets: Určuje přihlašovací údaje tajného klíče klienta, které se používají 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 je vyžadována 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 Connect a OAuth 2.0 definují řadu toků ověřování, mezi které patří:
- 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 spolu s dalšími 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
Použijte tok 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.
Mobilní aplikace eShopOnContainers se ověřuje pomocí IdentityServeru pomocí toku hybridního ověřování, který je znázorněn na obrázku 9–2.
Obrázek 9-2: Základní přehled procesu přihlašování
Do žádosti o přihlášení se provede <base endpoint>:5105/connect/authorizežádost o přihlášení . 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 pak odešle do <base endpoint>:5105/connect/tokenodpovědi na přístup, identitu a obnovovací tokeny.
Mobilní aplikace eShopOnContainers se odhlásí z IdentityServer odesláním požadavku s <base endpoint>:5105/connect/endsessiondalšími parametry. Jakmile dojde k odhlášení, IdentityServer odpoví odesláním identifikátoru URI přesměrování po odhlášení zpět do mobilní aplikace. Tento proces znázorňuje obrázek 9–3.
Obrázek 9-3: Základní přehled procesu odhlášení
V mobilní aplikaci eShopOnContainers 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 LOGIN na LoginView, spustí SignInCommand se třída LoginViewModel , která následně spustí metodu SignInAsync . Následující příklad kódu ukazuje tuto metodu:
private async Task SignInAsync()
{
...
LoginUrl = _identityService.CreateAuthorizationRequest();
IsLogin = true;
...
}
Tato metoda vyvolá metodu CreateAuthorizationRequest IdentityService ve třídě, která je zobrazena 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.Callback);
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 na mobilní aplikaci 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 IsLogin vlastnost stane true, stane se WebView v okně LoginView viditelné. Data WebView sváže svou Source vlastnost s LoginUrl vlastností LoginViewModel třídy, a proto vytvoří žádost o přihlášení k IdentityServer, když LoginUrl je vlastnost nastavena na autorizační koncový bod 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, která se zobrazí na obrázku 9–4.
Obrázek 9-4: Přihlašovací stránka zobrazená webview
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ě, která je znázorněna v následujícím příkladu kódu:
private async Task NavigateAsync(string url)
{
...
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))
{
Settings.AuthAccessToken = accessToken;
Settings.AuthIdToken = authResponse.IdentityToken;
await NavigationService.NavigateToAsync<MainViewModel>();
await NavigationService.RemoveLastFromBackStackAsync();
}
}
...
}
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á autorizační kód, ověřovací kód 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
Ověřte návratové identifikátory URI. I když mobilní 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 pak uloží jako nastavení aplikace a provede se navigace na stránce. Celkový účinek mobilní aplikace eShopOnContainers je tedy tento: za předpokladu, že uživatelé mohou úspěšně ověřit pomocí IdentityServer, přejdou na MainView stránku, což je TabbedPage stránka, která se zobrazí CatalogView jako vybraná karta.
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í přihlášení, když je aplikace nakonfigurovaná tak, aby používala napodobené služby v aplikaci SettingsView. V tomto režimu aplikace nekomunikuje se serverem IdentityServer a umožňuje uživateli přihlásit se pomocí jakýchkoli přihlašovacích údajů.
Odhlášení
Když uživatel klepne na tlačítko ODHLÁSIT se v ProfileViewsadě , LogoutCommand spustí se třída ProfileViewModel , která následně spustí metodu LogoutAsync . Tato metoda provádí navigaci na LoginView stránce a předává LogoutParameter instanci nastavenou true jako parametr. Další informace o předávání parametrů během navigace na stránce naleznete v tématu Předávání parametrů během navigace.
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;
}
...
}
Tato metoda vyvolá metodu CreateLogoutRequest IdentityService 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)
{
...
return string.Format("{0}?id_token_hint={1}&post_logout_redirect_uri={2}",
GlobalSetting.Instance.LogoutEndpoint,
token,
GlobalSetting.Instance.LogoutCallback);
}
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í. Další informace o uživatelských nastaveních najdete v tématu Správa konfigurace.
Vrácený identifikátor URI je uložen ve LoginUrl vlastnosti LoginViewModel třídy. I když je IsLogin truetato vlastnost , je zobrazena WebView v objektu LoginView . Data WebView sváže svou Source vlastnost s LoginUrl vlastností LoginViewModel třídy, a tak vytvoří žádost o odhlášení na IdentityServer, když LoginUrl je vlastnost nastavena na koncový bod relace IdentityServer. Když IdentityServer obdrží tento požadavek za předpokladu, že je přihlášený, dojde k odhláš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.
V mobilní aplikaci WebView se přesměruje na identifikátor URI přesměrování po odhlášení. 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)
{
...
Settings.AuthAccessToken = string.Empty;
Settings.AuthIdToken = string.Empty;
IsLogin = false;
LoginUrl = _identityService.CreateAuthorizationRequest();
...
}
Tato metoda vymaže token identity i přístupový token z nastavení aplikace a nastaví IsLogin vlastnost na false, která 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 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 MVC lze dosáhnout použitím atributu Authorize u kontroleru nebo akce, 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 class BasketController : Controller
{
...
}
Pokud se neoprávněný uživatel pokusí získat přístup k kontroleru nebo akci označené atributem Authorize , vrátí architektura MVC stavový kód HTTP 401 (neautorizováno).
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 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 na obrázku 9–5.
Obrázek 9–5: Autorizace pomocí přístupového tokenu
Mobilní 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 IdentityServeru 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 objednávku nebo kontroler košíku vrátí stavový kód HTTP 401 (neautorizováno), 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 během procesu ověřování zahrnut do požadavku, jak je znázorněno v následujícím příkladu kódu:
var authToken = Settings.AuthAccessToken;
Order = await _ordersService.GetOrderAsync(Convert.ToInt32(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 úložiště specifického pro platformu a zahrne se do volání UpdateBasketAsync metody ve BasketService třídě.
Třída RequestProvider v mobilní 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 HttpClient instance, 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 je odeslána od důvěryhodného vystavitele, a používá se k určení, jestli má uživatel oprávnění k vyvolání rozhraní API, které ho obdrží.
Další informace o tom, jak mobilní aplikace eShopOnContainers 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 Xamarin.Forms aplikace, která komunikuje s webovou aplikací ASP.NET MVC. Mobilní aplikace eShopOnContainers provádí ověřování a autorizaci pomocí mikroslužby kontejnerizované identity, která používá IdentityServer 4. IdentityServer je opensourcová architektura OpenID Connect a OAuth 2.0 pro ASP.NET Core, která se integruje s ASP.NET Základní identitou za účelem ověřování nosných tokenů.
Mobilní aplikace požaduje tokeny zabezpečení z IdentityServeru, a to buď pro ověřování uživatele, nebo pro přístup 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.