SAML2 vs JWT: Porozumění OpenID Connect části 1

Tento příspěvek vychází z toho, co jsme se dozvěděli o OAuth2 a JWT v předchozích příspěvcích. OpenID Connect nám poskytne poslední stavební blok pro případy použití související s JWT, které tato řada prozkoumá. Cílem tohoto příspěvku na blogu je poskytnout hluboké porozumění specifikaci OpenID Connect, aniž byste museli číst specifikace.

Historie OpenID

Existují tři generace technologie OpenID; OpenID Connect (OIDC) je třetí - vyšlo v listopadu 2014. Původní specifikace OpenID (první generace) byla zveřejněna v květnu 2005 Bradem Fitzpatrickem; to bylo původně odkazoval se, v tradici YACC - ještě další kompilátor kompilátoru - a YAML - ještě další značkovací jazyk, jak YADIS (ještě další distribuovaný identifikační systém). Specifikace OpenID druhé generace (OpenID v2.0) byla vydána v prosinci 2007.

Specifikace první generace nebyla široce přijata. Specifikace druhé generace měla mnohem větší adopci a vyspělost; nicméně, tam byla omezení designu včetně Relying strany (RP) mohl být webové aplikace (ale ne nativní aplikace) a to používalo XML.

Co je OpenID Connect?

Z openid.net je „OpenID Connect 1.0 jednoduchá vrstva identity nad protokolem OAuth 2.0. Umožňuje klientům ověřit totožnost koncového uživatele na základě autentizace prováděné autorizačním serverem a také získat základní informace o profilu koncového uživatele interoperabilním a REST podobným způsobem. “Toto„ podobné REST “ způsobem ”dělá OIDC spíš jako API (v souladu s OAuth2) než předchozí generace OpenID. OIDC rozšiřuje udělení autorizačního kódu OAuth2 (třínohé OAuth).

OIDC staví na lekcích časných protokolů OpenID a SAML2 včetně:

  • udržujte věci jednoduché
  • stavět na OAuth2
  • používat snadno konzumovatelné tokeny (JWT)

OIDC se může integrovat s

  • tradiční webové aplikace
  • mobilní aplikace
  • Jednostránkové aplikace (aplikace SPA)
  • serverové aplikace
  • většina ostatních herců

OIDC se skládá z následujících specifikací (z openid.net):

  • Jádro (povinné): základní funkce OIDC: autentizace postavená na OAuth 2.0 a použití nároků pro komunikaci informací o koncovém uživateli.
  • Discovery (volitelné): Jak klienti dynamicky objevují informace o poskytovatelích OpenID (tj. Autorizačních serverech nebo poskytovatelích identity).
  • Dynamická registrace (volitelné): jak se klienti dynamicky registrují u poskytovatelů OpenID.
  • Více typů odpovědí OAuth 2.0 (povinné): Definuje několik konkrétních nových typů odpovědí OAuth 2.0.
  • Režim odpovědi na odpověď OAuth 2.0 (volitelné): Definuje, jak vrátit parametry odpovědi na autorizaci OAuth 2.0 (včetně parametrů OIDC Authentication Response) pomocí hodnot formuláře HTML, které jsou automaticky odesílány agentem uživatele pomocí HTTP POST
  • Správa relací (volitelné): Definuje způsob správy relací OIDC, včetně funkce odhlášení od post-Message
  • Odhlášení z předního kanálu (volitelné): Definuje mechanismus odhlášení z předního kanálu, který na stránkách RP nepoužívá prvek iframe OP.
  • Odhlášení zpětného kanálu (volitelné): Definuje mechanismus odhlášení, který používá komunikaci zpětného kanálu mezi odhlášenými OP a RP.

K dispozici jsou také dva průvodce implementátora, kteří slouží jako samostatné reference pro implementátory základních spolehlivých webových stránek:

  • Příručka základního implementátora klienta: Jednoduchá podmnožina základních funkcí pro webovou spoléhající stranu využívající tok kódu OAuth
  • Příručka Implicit Client Implementer's Guide: Jednoduchá podmnožina základních funkcí webové spolehlivé strany používající OAuth Implicit Flow

K dispozici je také specifikace migrace protokolu:

  • Migrace OpenID 2.0 na OpenID Connect 1.0: Definuje migraci z OpenID 2.0 na OIDC

Stejný web má také základ následující tabulky, která ukazuje tyto specifikace a podpůrné specifikace:

Rodina specifikací OIDC a podpůrných specifikací.

Herci

Specifikace OIDC definuje několik herců.

Relying Party (RP): Toto je nový termín vypůjčený od specifikace SAML2. Klientská aplikace OAuth2 vyžadující ověření koncového uživatele a nároky od poskytovatele OpenID. Poskytovatel OpenID (viz níže) bezpečně vrací autentizační odpověď klientovi OAuth2, aby se na něj mohlo spolehnout; v této souvislosti se tedy klient nazývá spoléhající stranou.

Poskytovatel OpenID (OP): Autorizační server OAuth 2.0, který je schopen ověřit koncového uživatele a poskytnout nároky spoléhající straně na událost ověřování a koncového uživatele (podle specifikace OIDC).

Koncový uživatel: Tento výraz byl přítomen v protokolu OAuth2. Princip, který je autentizovaný (nejpravděpodobnější člověk).

User Agent: Tento výraz byl přítomen v OAuth2. Něco, co iniciuje požadavky HTTPS a dokáže zpracovat přesměrování generovaná klientem a poskytovatelem OpenID. Obvykle se jedná o User Agent nebo knihovnu, která dokáže zpracovat volání OIDC.

Zdrojový server: Tento výraz byl přítomen v protokolu OAuth2. Server hostující chráněné prostředky, schopný přijímat a reagovat na požadavky chráněných zdrojů pomocí přístupových tokenů.

Změny na ID token (JWT)

Nároky definované ve specifikaci JWT jsou popsány v příspěvku „SAML2 vs. JWT: Porozumění JSON Web Token (JWT)“. Kromě toho, co vyžadují specifikace JWT a JWS, vyžaduje specifikace OIDC následující nároky v JWT, které fungují jako ID token. Tyto požadavky se nemusí nutně vztahovat na token JWT, který funguje jako přístupový token. Zde uvedené popisy jsou parafrázovány z úplného popisu specifikace.

„Iss“ (Emitent) Nárok: identifikátor poskytovatele identity, který vydal JWT. Toto je velká a malá písmena URL používající schéma HTTPS. Toto tvrzení je nyní nutné.

„Sub“ (Předmět) Nárok: identifikátor subjektu. Lokálně jedinečný a nikdy nepřidělený identifikátor v rámci Emitenta pro Koncového uživatele, který je určen ke spotřebě Klientem. Toto tvrzení je nyní nutné.

„Aud“ (Publikum) Prohlášení: publikum, pro které je tento token ID určen. Jako hodnotu publika musí obsahovat klientský ID OAuth 2.0 Relying Party. Může to být řada řetězců citlivých na velikost písmen; může také obsahovat jediný řetězec citlivý na velikost písmen (výše uvedený klient_id). Toto tvrzení je nyní nutné.

„Exp“ (Expirace) Nárok: čas, po kterém nebo po kterém ID token nesmí být přijat ke zpracování. Klient může přidat zkosení hodin. Toto tvrzení je nyní nutné.

„Iat“ (Vydáno v době) Nárok: čas, kdy byla vydána JWT. Toto tvrzení je nyní nutné.

„Auth_time“ (autentizovaný předmět času) Nárok: čas, kdy došlo k ověření koncového uživatele. Může být požadováno v závislosti na případu použití.

„Nonce“ (nonce) Nárok: hodnota řetězce používaná k přiřazení relace klienta k ID tokenu a ke zmírnění opakovaných útoků. Může být požadováno v závislosti na případu použití.

„Acr“ (Reference třídy kontextu autentizace): řetězec obsahující informace o tom, jak byl hlavní zmocněnec autentizován; hodnota „0“ znamená, že autentizace nesplnila požadavky normy ISO / IEC 29115. Tento požadavek je volitelný.

„Amr“ (Reference Authentication Methods Reference) Prohlášení: JSON pole řetězců, které jsou identifikátory metody autentizace, které popisují, jak bylo provedeno ověření koncového uživatele. Identifikátory jsou mimo rozsah specifikace OIDC; takže každý OP bude definovat své vlastní. Toto tvrzení je volitelné.

„Azp“ (autorizovaná strana) Nárok: strana, které byl vydán identifikační klíč. Pokud je přítomen, MUSÍ obsahovat ID klienta OAuth 2.0 této strany. To je nutné pouze v případě, že pole publika obsahuje jednu hodnotu (identifikátor klienta RP) a tato hodnota se liší od autorizované strany. Toto tvrzení je volitelné.

“At_hash” (hodnota hash Access Token) Nárok: hash hodnota access_token pomocí algoritmu hash uvedeného v parametru alg Header Parameter. Tento nárok může být vyžadován v závislosti na toku.

„C_hash“ (hash autorizačního kódu) Nárok: hash hodnota hodnoty parametru kódu pomocí algoritmu hash uvedeného v parametru záhlaví „alg“. V zásadě je to stejná věc jako v případě nároku „at_hash“, ale v autorizačním kódu. Tento nárok může být vyžadován v závislosti na toku.

„Sub_jwk“ (veřejný klíč digitálního podpisu OpenID poskytovatele s vlastním vydáním) Nárok: Veřejný klíč používaný ke kontrole podpisu ID tokenu vydaného samoobslužným OP (osobní, hostovaný OP, který vydává samopodepsané tokeny) OP. Klíč je holý klíč ve formátu JWK (nikoli ve formátu X. 509). Pokud OP není vydán sám, nemělo by se toto tvrzení použít.

Další informace o těchto tvrzeních naleznete v části 2 specifikace OIDC. Nároky, které nejsou pochopeny, musí být ignorovány. Token JWT fungující jako ID token by neměl obsahovat pole parametrů záhlaví JWS nebo JWE:

  • x5u
  • x5c
  • jku
  • jwk

Místo toho by tyto informace měly být poskytovány prostřednictvím Discovery Document OP nebo jinými prostředky (viz oddíl 10 specifikace OIDC).

OIDC specifikace také definuje četné standardní nároky, které mohou být zahrnuty (na žádost) do odpovědi ID Token nebo UserInfo. Zda jsou dodatečné nároky zahrnuty do ID tokenu nebo načteny z koncového bodu UserInfo, bude záviset na funkcích podporovaných dodavatelem OP.

JWT působící jako ID token musí být podepsán (JWS) a volitelně šifrován (JWE). Pokud je použito šifrování, musí být JWT podepsán a poté zašifrován. Tyto kroky poskytují „autentizaci, integritu, nevypovědení a volitelně důvěrnost“.

Jak se OIDC liší od OAuth 2.0?

Přímo ze specifikace máme „primární rozšíření, které OIDC provádí pro OAuth 2.0, aby bylo umožněno ověření koncových uživatelů, je datová struktura ID Token.“ Takže OIDC přináší do obrázku JWT - a rozšířením to změní na něco to začíná být velmi srovnatelné s tím, co je ve hře v případech použití SAML2.

Specifikace OAuth2 a OIDC se zabývají mnoha stejnými případy použití, ale specifikace OAuth2 k tomu přichází z pohledu delegované autorizace (klientská aplikace založená na přístupu, který koncový uživatel umožňuje svým prostředkům hostovaným na třetí straně server). Specifikace OAuth2 řeší různé případy použití nad rámec třínohých OAuth, ale zde začaly původní specifikace OAuth a to, co rozšiřuje OIDC. V každém případě se jedná o delegované oprávnění. Podrobnosti o tom, jak autentizace funguje, a pokročilejší funkce zaměřené na autentizaci nejsou v OAuth2 definovány - zde začíná OIDC. OIDC je ověřovací protokol; je postaven na udělení autorizačního kódu OAuth2. Jinak řečeno, OIDC je profil OAuth2.

OIDC přidá do OAuth2 následující autentizační funkce:

  • Standardizace nároků (standardní sada nároků přítomná v ID tokenu).
  • Nařizuje použití digitálně podepsaného (a volitelně šifrovaného) tokenu (JWT) jako datové struktury ID Token, která obsahuje informace o uživateli (Nároky). Zajímavé je, že toho lze dosáhnout také nařízením, aby samotný přístupový token byl JWT; má to však bezpečnostní důsledky, na které se podíváme později. Zavedení ID tokenu znamená, že krok autentizace na RP se nyní spoléhá na ID token a ne Access token (na rozdíl od OAuth2).
  • Poskytuje mechanismus podobný artefaktu SAML2 SAML prostřednictvím koncového bodu UserInfo. To umožňuje zjistit, jaké nároky vidí různí aktéři.
  • Umožňuje vynucení autentizace koncového uživatele (i když již je přihlášený do OP)
  • Možnost klientů požadovat další nároky (ID token nebo Userinfo Endpoint, jak bylo uvedeno dříve)
  • Identifikujte, jak byl ověřen koncový uživatel (tj. Ověřovací kontext, nárok ACR, v ID tokenu).
  • Úroveň ochrany přístupových tokenů. To se týká použití šifrování (JWE) a podpisů (JWS) na ID tokenu. Tyto údaje budou konfigurovány během procesu registrace klienta. Při zkoumání tohoto článku jsem hledal mechanismus run-time (parametr připojený k žádosti o ověření), který by klientovi umožnil určit, jakou úroveň ochrany by měla být zahrnuta do ID Token, ale nezdá se, že existuje jeden .
  • Podpora distribuovaných a agregovaných nároků. Tato řada příspěvků o těchto funkcích nejde podrobněji. Viz oddíl 5.6.2 specifikace OIDC.
  • Dynamické úvody (úvody klientů a on-boarding). Stejně tak se k tomuto tématu nebudeme dále zabývat.

Koncové body OIDC

OP inzeruje následující koncové body.

Koncový bod autorizace

Koncový bod autorizace je definován specifikací OAuth2. Tento koncový bod odpovídá za ověření a získání souhlasu koncového uživatele. Další podrobnosti naleznete zde. Požadavky OIDC na tento koncový bod se skládají z parametrů, které jsou definovány ve specifikacích OAuth2 a OIDC. Viz diskuse o autentizačních postupech níže.

Token Endpoint

Koncový bod tokenu je definován také specifikací OAuth2. Tento koncový bod je zodpovědný za to, že klientovi umožňuje vyměnit autorizační kód nebo identifikátor klienta a tajné informace o klientovi za přístupový token. Další podrobnosti naleznete zde. OIDC požadavky na tento koncový bod se skládají z parametrů, které jsou definovány ve specifikacích OIDC. Viz diskuse o autentizačních postupech níže.

UserInfo Endpoint

Koncový bod UserInfo je definován specifikací OIDC. Umožňuje herci (klientovi nebo serveru zdrojů) požadovat další nároky.

Pro načtení standardní sady nároků z koncového bodu UserInfo poskytovatele OpenID by měla být odeslána žádost podobná následující (kde token v hlavičce Autorizace je přístupový token, který byl předložen klientovi).

GET / oidc / userinfo HTTP / 1.1
Hostitel: server.example.com
Autorizace: Nositel PHNhbWxwOl… [vynecháno pro stručnost]… ZT4

Odpověď by vypadala něco takového.

HTTP / 1,1 200 OK
  Content-Type: application / json

  {
   "sub": "john.smith@levvel.io",
   "jméno": "John Smith",
   "dané_jméno": "John",
   "family_name": "Smith",
   "preferované uživatelské jméno": "john.smith@levvel.io",
   "email": "john.smith@levvel.io"
  }

Pokud herec požaduje podpis a / nebo šifrování, bude vrácena JWT s příslušnou aplikací specifikací JWS a JWE.

souhrn

Tento příspěvek poskytl úvod k konceptům OIDC. V dalším příspěvku začneme zkoumat autentizační toky definované specifikací OIDC.

Otázky? Komentáře? Zveřejněte je níže.