Pozn. přek.: V tomto skvělém materiálu společnosti Okta jsou jednoduše a názorně vysvětleny principy fungování OAuth a OIDC (OpenID Connect). Tyto znalosti budou užitečné pro vývojáře, systémové administrátory a dokonce i pro „běžné uživatele“ oblíbených webových aplikací, které pravděpodobně také vyměňují citlivé údaje s jinými službami.
Ve „věku kamenném“ internetu bylo sdílení informací mezi službami snadné. Jednoduše jste dali své přihlašovací údaje z jednoho služby druhé, aby se mohla přihlásit do vašeho účtu a získat všechny potřebné informace.
„Poskytněte nám svou bankovní účet.“ — „Slibujeme, že s heslem a penězi bude vše v pořádku. Opravdu upřímně!“ *haha*
Hrůza! Nikdo a nikdy by neměl po uživateli požadovat, aby sdílel své přihlašovací údaje uživatelská jména, s jinou službou. Neexistuje žádná záruka, že organizace, která za touto službou stojí, bude uchovávat údaje v bezpečí a neshromáždí více osobních informací, než je potřeba. Možná to vypadá šíleně, ale některé aplikace stále tuto praxi používají!
Dnes existuje jediný standard, který umožňuje jedné službě bezpečně využívat data jiné. Bohužel, podobné standardy obsahují spoustu žargonu a termínů, což ztěžuje jejich pochopení. Cílem tohoto materiálu je pomocí jednoduchých ilustrací vysvětlit, jak fungují (Myslíte, že moje kresby připomínají dětskou čmáranici? No a co!).
Mimochodem, tato příručka je také dostupná ve formátu videa:
Dámy a pánové, představujeme: OAuth 2.0
— to je bezpečnostní standard, který umožňuje jedné aplikaci získat oprávnění k přístupu k informacím v jiné aplikaci. Postup pro udělení oprávnění [permission] (nebo souhlasu [consent]) se často nazývá autorizací [authorization] nebo dokonce delegovanou autorizací [delegated authorization]. Díky tomuto standardu umožňujete aplikaci číst data nebo používat funkce jiné aplikace vaším jménem, aniž byste jí sdíleli své heslo. Skvělé!
Jako příklad si představte, že jste našli web s názvem „Nejhroznější vtip dne“ [Terrible Pun of the Day] a rozhodli jste se na něm zaregistrovat, abyste každý den dostávali vtipy ve formě textových zpráv na telefon. Web se vám velmi zalíbil a rozhodli jste se ho sdílet se všemi známými. Vždyť strašlivé vtipy se líbí všem, že?
„Neúspěšná vtipná hláška dne: Slyšeli jste o chlapíkovi, který ztratil levou polovinu těla? Teď má vždy pravdu!“ (překlad je přibližný, protože v originále je to slovní hříčka — pozn. překl.)
Je jasné, že psát každému člověku ze seznamu kontaktů není možnost. A pokud se alespoň trochu podobáte mně, uděláte cokoliv, abyste se vyhnuli zbytečné práci. Naštěstí může Terrible Pun of the Day pozvat všechny vaše přátele sám! Stačí mu otevřít přístup k e-mailu kontaktů — web sám odešle pozvánky (OAuth to zařídí)!
„Všichni milují vtipy! — Už jste se přihlásili? — Chcete poskytnout webu Terrible Pun of the Day přístup k seznamu kontaktů? — Děkujeme! Teď budeme každý den posílat připomínky všem, které znáte, až do konce věků! Jste nejlepší přítel!“
- Vyberte si svůj e-mailový servis.
- Pokud je to nutné, přejděte na stránku e-mailu a přihlaste se do svého účtu.
- Dejte povolení webu Terrible Pun of the Day na přístup k kontaktům.
- Vraťte se na web Terrible Pun of the Day.
Pokud byste náhodou změnili názor, aplikace využívající OAuth také nabízejí způsob, jak zrušit přístup. Pokud se rozhodnete, že už nechcete sdílet kontakty s Terrible Pun of the Day, můžete přejít na stránku e-mailu a odstranit tento web s vtipy ze seznamu autorizovaných aplikací.
OAuth tok
Právě jsme prošli tím, co se obvykle nazývá tok [flow] OAuth. V našem příkladu se tento tok skládá z viditelných kroků, ale také z několika neviditelných kroků, v rámci kterých si dva služby dohodnou bezpečnou výměnu informací. V předchozím příkladu s Terrible Pun of the Day je použit nejběžnější tok OAuth 2.0, známý jako tok „s autorizačním kódem“ [„authorization code“ flow].
Před tím, než se ponoříme do detailů fungování OAuth, pojďme si promluvit o významu některých pojmů:
- Vlastník zdroje:
To jste vy! Vlastníte svá přihlašovací údaje, svá data a řídíte všechny akce, které mohou být provedeny s vašimi účty. - Client:
Aplikace (například služba Terrible Pun of the Day), která chce získat přístup nebo provést určité akce jménem Vlastník zdrojeuživatele. - Autentizační server:
Aplikace, která ví Vlastník zdrojeo uživateli a ve které má Vlastník zdrojeuživatel již účet. - Resource Server:
Programové rozhraní aplikace (API) nebo služba, kterou Client se chce využít jménem Vlastník zdrojeuživatele. - Přesměrovací URI:
Odkaz, na který Autentizační server přesměruje Vlastník zdrojeuživatele po poskytnutí povolení Client. Někdy se jí říká "Return URL" ("Callback URL"). - Typ odpovědi:
Typ informace, kterou očekává získat Client. Nejrozšířenější Typ odpovědityp odpovědi je kód, tedy Client očekává získat Pověřovací kód. - Rozsah:
To je podrobný popis oprávnění, která jsou vyžadována Clientuživateli, jako je přístup k datům nebo provádění určitých akcí. - Souhlas:
Autentizační server žádá o oprávnění, požadované Clientuživateli, a ptá se Vlastník zdrojeuživatele, zda je ochoten poskytnout Clientuživateli odpovídající oprávnění. - Client ID:
Tento ID se používá k identifikaci Clientuživatele na Autentizační serverserveru. - Tajný klíč klienta:
To je heslo, které zná pouze Clientuživatel a Autentizační serverserver. Umožňuje jim důvěrně sdílet informace. - Pověřovací kód:
Dočasný kód s krátkou platností, který Client poskytuje Autentizační serveruživatel použije výměnou za Přístupový token. - Přístupový token:
Klíč, který klient použije pro komunikaci s Resource Serverserverem. Jakýsi odznak nebo klíčová karta, který poskytuje Clientuživateli oprávnění na požadování dat nebo provádění akcí na Resource Serverserveru jménem vás.
Poznámka: někdy je autentizační server a resource server jedním a tím samým serverem. V některých případech to však mohou být různé servery, které ani nepatří jedné organizaci. Například autentizační server může být třetí stranou, které důvěřuje resource server.
Nyní, když jsme se seznámili se základními pojmy OAuth 2.0, vraťme se k našemu příkladu a podívejme se blíže na to, co se děje v toku OAuth.
- Vy, Vlastník zdrojechuťte poskytnout službě Terrible Pun of the Day (Clientuživateli) přístup k vašim kontaktům, aby mohl rozeslat pozvánky všem vašim přátelům.
- Client přesměrovává prohlížeč na stránku Autentizační serverserveru a zahrnuje do žádosti Client ID, Přesměrovací URI, Typ odpovědi jedno nebo více o oprávnění povolení, které potřebuje.
- Autentizační server ověřuje vás, přičemž případně žádá o uživatelské jméno a heslo.
- Autentizační server vytváří formulář Souhlas (potvrzení) se seznamem všech o oprávněnípovolení, které Clientuživatel žádá. Souhlasíte nebo odmítáte.
- Autentizační server přesměrovává vás na web Clientuživatele, používající Přesměrovací URI spolu s Pověřovací kód (kód pro autorizaci).
- Client přímo se spojuje s Autentizační serveruživatelem (obešel prohlížeč Vlastník zdrojeuživatele) a bezpečně odesílá Client ID, Tajný klíč klienta a Pověřovací kód.
- Autentizační server ověřuje data a odpovídá s Přístupový token‘tokenem přístupu).
- Nyní Client může používat Přístupový token pro odeslání žádosti na Resource Server za účelem získání seznamu kontaktů.
Client ID a Secret
Dlouho předtím, než jste povolili Terrible Pun of the Day přístup k kontaktům, Client a Authorization Server si vytvořili pracovní vztah. Authorization Server vygeneroval Client ID a Client Secret (někdy se jim říká App ID a App Secret) a poslal je Clientovi pro další interakci v rámci OAuth.
„Ahoj! Chtěl bych s tebou pracovat! – Žádný problém! Tady máš své Client ID a Secret!“
Název naznačuje, že Client Secret by měl být uchován v tajnosti, aby ho znali pouze Client a Authorization Server. Protože právě s jeho pomocí Authorization Server ověřuje pravost Clienta.
Ale to ještě není všechno… Prosím, přivítejte OpenID Connect!
OAuth 2.0 byl navržen pouze pro autorizace – poskytování přístupu k datům a funkcím z jedné aplikace do druhé. (OIDC) – to je tenký vrstva nad OAuth 2.0, která přidává informace o přihlášení a profilu uživatele, který se přihlásil do účtu. Organizaci přihlašovacích relací často nazýváme autentizací [authentication], a informace o uživateli, který se přihlásil (tj. o Vlastník zdroje‘ně), – osobními údaji [identity]. Pokud Authorization Server podporuje OIDC, někdy se mu říká poskytovatel osobních údajů [identity provider], protože poskytuje Client‘u informace o Vlastník zdrojeserveru.
OpenID Connect umožňuje realizovat scénáře, kdy je možné použít jediné přihlášení napříč několika aplikacemi, – tento přístup je také znám jako single sign-on (SSO). Například aplikace může podporovat SSO integraci se sociálními sítěmi, jako je Facebook nebo Twitter, umožňující uživatelům používat účet, který již mají a který preferují používat.
Tok (flow) OpenID Connect vypadá stejně jako v případě OAuth. Jediný rozdíl je v tom, že v prvotní žádosti je použit konkrétní scope – openid, – a Client nakonec získá jako Přístupový token, tak i ID Token..
Stejně jako v toku OAuth, Přístupový token v OpenID Connect – to je určitá hodnota, nesrozumitelná Client‘u. Z pohledu Client‘a Přístupový token představuje určitý řetězec znaků, který je přenášen spolu s každou žádostí k Resource Server‘u, a ten určuje, zda je token platný. ID Token. představuje úplně něco jiného.
ID Token – to je JWT
ID Token. – to je speciálně formátovaný řetězec znaků, známý jako JSON Web Token nebo JWT (někdy se tokeny JWT vyslovují jako „jots“). Třetím stranám se může zdát, že JWT je nesrozumitelná abeceda, nicméně Client je možné z JWT vytáhnout různé informace, jako je ID, uživatelské jméno, čas přihlášení do účtu a expirace ID Token.a případné pokusy o manipulaci s JWT. Data uvnitř ID Token.se nazývají nároky [claims].
V případě OIDC existuje také standardní způsob, pomocí kterého Client možná požádat o další informace o identitě [identity] od Autentizační servernapříklad e-mailovou adresu, pomocí Přístupový token.
Další informace o OAuth a OIDC
Tedy jsme se stručně podívali na principy fungování OAuth a OIDC. Chcete jít hlouběji? Zde jsou další zdroje, které vám pomohou dozvědět se více o OAuth 2.0 a OpenID Connect:
Jak obvykle, neváhejte komentovat. Abyste byli informováni o našich nejnovějších novinkách, přihlaste se k odběru a informací od společnosti Okta pro vývojáře!
P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
