🥇IdentityServer4. Základní pojmy. OpenID Connect, OAuth 2.0 a JWT

Tento příspěvek chci věnovat sérii článků na téma IdentityServer4. Začneme základními pojmy.

Nejperspektivnějším stávajícím autentizačním protokolem je OpenID Connect, zatímco protokolem autorizace (poskytování přístupu) je OAuth 2.0. IdentityServer4 implementuje tyto dva protokoly. Je optimalizován pro řešení typických problémů bezpečnosti.

OpenID Connect — to je protokol a standard autentizace, nezajišťuje přístup k prostředkům (Web API), ale protože je vyvinut na základě protokolu autorizace OAuth 2.0, umožňuje získat parametry profilu uživatele, jako byste získali přístup k prostředku UserInfo.
JWT (JSON Web Token) představuje webový standard, který určuje způsob přenosu informací o uživateli ve formátu JSON v šifrované podobě.
OAuth 2.0 (RFC 6749) — to je protokol a standard autorizace. Umožňuje aplikacím získat přístup k chráněným prostředkům, například k Web API.

Podívejme se na diagram přístupu k chráněnému prostředku a prozkoumejme základní kroky a přijatou terminologii:

Klient žádá uživatele o povolení autorizovat ho jeho jménem. Zákazník — to je klientská aplikace, která přistupuje k chráněným prostředkům jménem vlastníka prostředků. Zdrojem — to jsou všechny naše chráněné služby Web API.
Uživatel povoluje klientské aplikaci, aby se autorizovala jeho jménem, například zadáním uživatelského jména a hesla. Uživatelské jméno a heslo budou představovat grant autorizace pro klientskou aplikaci. Uživatel (vlastník prostředku) — program nebo osoba, která může udělit přístup k chráněným prostředkům, například zadáním uživatelského jména (username) a hesla (password);
Klientská aplikace žádá o přístupový token u IdentityServer4 poskytnutím informací o sobě (client_id, client_secret), poskytnutím povolení k autorizaci od uživatele (uživatelské jméno, heslo) a poskytnutím grant_type a scope. Poté server autorizace ověřuje platnost klienta a údaje vlastníka prostředku (uživatelské jméno a heslo).
Protokol OAuth 2.0 provádí autentizaci nejen uživatele, ale i klientské aplikace, která přistupuje k prostředkům. Pro tento účel protokol zahrnuje takové parametry jako client_id a client_secret.
client_id — to je identifikátor klientské aplikace, který se používá IdentityServer4 k nalezení informací o klientovi.
client_secret je analogií hesla pro klientskou aplikaci a používá se k autentizaci klientské aplikace na IdentityServer4. Tajný klíč klienta by měl být znám pouze aplikaci a API. Na základě výše uvedeného můžeme uzavřít, že IdentityServer4 musí vědět o svých klientech.
Pokud je platnost aplikace potvrzena a oprávnění k autorizaci je skutečně platné, IdentiryServer4 vytváří access token (přístupový token) pro aplikaci a volitelný refresh token (refresh token). Proces autorizace je dokončen. Pokud je žádost neplatná nebo neoprávněná, server autorizace vrací kód s odpovídající chybovou zprávou.
Klientská aplikace žádá o data od chráněného Web API, přičemž poskytuje přístupový token pro autorizaci. Pokud kód odpovědi serveru zdrojů 401, 403 nebo 498, pak je přístupový token, který se používá pro autentizaci, neplatný nebo vypršel.
Pokud je token platný, Web API poskytuje údaje aplikaci.

Typy tokenů

Zaregistrovaným v IdentityServer4 klientům je povoleno požadovat IdentityServer4 identity-token, access-token a Obnovit obrazy-token.

identity token (token identity) — výsledek procesu autentizace. Obsahuje identifikátor uživatele a informace o tom, jak a kdy uživatel prochází autentizací. Lze rozšířit o vlastní data.
access token (přístupový token) — předává se chráněnému API a používá se mu k autorizaci (udělení přístupu) k vlastním datům.
refresh token (token obnovy) — volitelný parametr, který může server autorizace vrátit jako odpověď na žádost o přístupový token.

Zavedeme ještě dva pojmy:

Authentication Server Url — koncový bod pro získání přístupového klíče. Všechny žádosti o udělení a obnovení přístupových klíčů budeme směřovat na tuto URL adresu.

Resource Url — URL adresa chráněného zdroje, na kterou je třeba se obrátit, abyste k ní získali přístup, přičemž se mu předá přístupový klíč v autorizačním hlavičce.

Žádost o přístupový klíč

Pro žádost o přístupový klíč klient provede POST žádost k koncovému bodu IdentityServer4 s následujícími hlavičkami

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

a předáním následujících parametrů:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

uživatelské jméno, heslo, client_id a client_secret byly rozebrány výše. Prozkoumejme ostatní parametry:

grant_type — typ grantů nebo typ oprávnění k autorizaci. Typ oprávnění k autorizaci závisí na metodě žádosti o autorizaci používané aplikací a na typech oprávnění, které API podporuje. V našem případě bude mít hodnotu heslo, což podle specifikace OAuth 2.0 odpovídá grantům přihlašovacích údajů vlastníka zdroje (autorizace pomocí přihlašovacího jména a hesla).

Protokol OAuth 2.0 určuje následující typy grantů, které vyžadují povinnou interakci s uživateli:

kód autorizace (authorization code). Je jedním z nejrozšířenějších typů oprávnění k autorizaci, protože se dobře hodí pro serverové aplikace (server-side applications), kde není přístupný zdrojový kód aplikace a klientský tajný klíč je nedostupný pro třetí strany;
implicitní (implicit). Implicitní typ oprávnění k autorizaci se používá mobilními a webovými aplikacemi, kde nelze zaručit důvěrnost tajného klíče klienta;

A typy grantů, které mohou probíhat bez interaktivní interakce s uživateli:

údaje vlastníka zdroje (resource owner). Tento typ oprávnění by se měl používat pouze v případě, že je klientská aplikace důvěryhodná pro uživatele a uživatel je pohodlný s zadáváním svého přihlašovacího jména a hesla. Tento typ oprávnění by se měl používat pouze v případě, že nejsou dostupné jiné možnosti. Tento typ oprávnění je pohodlný pro firemní klienty, kteří ve své systému již využili uživatelské údaje a chtějí přejít na OAuth 2.0.
údaje klienta. Používají se při přístupu aplikace k API. To může být užitečné například, když aplikace chce aktualizovat své vlastní registrační informace na službě nebo URI přesměrování, nebo získat přístup k dalším informacím uloženým v účtu aplikace na službě prostřednictvím API služby.

scope — je volitelný parametr. Určuje rozsah viditelnosti. Přístupový token navrácený serverem bude poskytovat přístup pouze k těm službám, které spadají do tohoto rozsahu. Tedy můžeme několik služeb spojit pod jedním rozsahem a pokud klient získá přístupový klíč k tomuto rozsahu, získá přístup ke všem těmto službám. Také rozsah může být použit k omezení autorizovaných práv (například pro čtení nebo zápis).

Zdroj: habr.com