Poznámka. přel.: Tento skvělý článek od Okta vysvětluje, jak OAuth a OIDC (OpenID Connect) fungují jednoduchým a jasným způsobem. Tyto znalosti se budou hodit vývojářům, systémovým administrátorům a dokonce i „běžným uživatelům“ populárních webových aplikací, které si velmi pravděpodobně také vyměňují důvěrná data s jinými službami.
V době kamenné internetu bylo sdílení informací mezi službami snadné. Jednoduše jste dali své přihlašovací jméno a heslo z jedné služby do druhé, takže zadal váš účet a obdržel všechny potřebné informace.
"Dejte mi svůj bankovní účet." „Slibujeme, že s heslem a penězi bude vše v pořádku. To je upřímné, upřímné!" *hee hee*
Hrůza! Nikdo by nikdy neměl vyžadovat, aby uživatel sdílel uživatelské jméno a heslo, pověření, s jinou službou. Neexistuje žádná záruka, že organizace stojící za touto službou bude uchovávat data v bezpečí a nebude shromažďovat více osobních údajů, než je nutné. Může to znít bláznivě, ale některé aplikace tuto praxi stále používají!
Dnes existuje jednotný standard, který umožňuje jedné službě bezpečně používat data druhé. Bohužel tyto normy používají mnoho žargonu a termínů, což komplikuje jejich pochopení. Účelem tohoto materiálu je vysvětlit, jak fungují pomocí jednoduchých ilustrací (Myslíte si, že moje kresby připomínají dětské mazanice? No dobře!).
Mimochodem, tato příručka je k dispozici také ve formátu videa:
Dámy a pánové, vítejte: OAuth 2.0
je bezpečnostní standard, který umožňuje jedné aplikaci získat oprávnění pro přístup k informacím v jiné aplikaci. Posloupnost kroků pro vydání povolení [povolení] (nebo souhlas [souhlas]) často volat oprávnění [oprávnění] nebo delegované oprávnění [delegované oprávnění]. Pomocí tohoto standardu umožňujete aplikaci číst data nebo používat funkce jiné aplikace vaším jménem, aniž byste jí poskytli své heslo. Třída!
Řekněme například, že objevíte web s názvem „Nešťastná hříčka dne“ [Hrozná hříčka dne] a rozhodl se na něm zaregistrovat, aby mohl denně dostávat slovní hříčky ve formě textových zpráv na telefon. Stránka se vám velmi líbila a rozhodli jste se ji sdílet se všemi svými přáteli. Koneckonců, každý má rád strašidelné slovní hříčky, že?
„Nešťastná hříčka dne: Slyšeli jste o chlápkovi, který přišel o levou polovinu těla? Teď má vždycky pravdu!" (přibližný překlad, protože originál má svoji slovní hříčku - cca přel.)
Je jasné, že psát každému člověku ze seznamu kontaktů není možné. A pokud jste alespoň trochu jako já, pak uděláte vše pro to, abyste se vyhnuli zbytečné práci. Naštěstí dokáže Terrible Pun of the Day pozvat všechny vaše přátele sama! Chcete-li to provést, stačí otevřít přístup k e-mailu vašich kontaktů – samotný web jim pošle pozvánky (pravidla OAuth)!
„Každý miluje slovní hříčky! - Již přihlášen? „Chtěli byste povolit webu Strašidelná hříčka dne přístup k vašemu seznamu kontaktů? - Děkuji! Od této chvíle budeme posílat upomínky každý den všem, které znáte, až do konce věků! Jsi nejlepší přítel!"
- Vyberte svou e-mailovou službu.
- V případě potřeby přejděte na poštovní stránku a přihlaste se ke svému účtu.
- Dejte Terrible Pun of the Day povolení k přístupu k vašim kontaktům.
- Vraťte se na stránku Hrozná hříčka dne.
V případě, že si to rozmyslíte, aplikace využívající OAuth také poskytují způsob, jak zrušit přístup. Jakmile se rozhodnete, že již nechcete sdílet kontakty s Terrible Pun of the Day, můžete přejít na e-mailovou stránku a odstranit stránku s hříčkami ze seznamu autorizovaných aplikací.
Tok OAuth
Právě jsme prošli tím, co se obvykle nazývá tok [tok] OAuth. V našem příkladu se tento tok skládá z viditelných kroků a také z několika neviditelných kroků, ve kterých se dvě služby dohodnou na bezpečné výměně informací. Předchozí příklad Terrible Pun of the Day používá nejběžnější tok OAuth 2.0, známý jako tok „autorizačního kódu“. [tok "autorizačního kódu"].
Než se ponoříme do podrobností o tom, jak OAuth funguje, promluvme si o významu některých termínů:
- Vlastník zdroje:
To jsi ty! Vlastníte své přihlašovací údaje, svá data a řídíte všechny aktivity, které mohou být prováděny na vašich účtech. - Klient:
Aplikace (například služba Terrible Pun of the Day), která chce získat přístup k určitým akcím nebo jejich jménem provádět určité akce Vlastník zdroje'A. - Autorizační server:
Aplikace, která ví Vlastník zdroje'a ve kterém u Vlastník zdroje'a už mám účet. - zdrojový server:
Aplikační programovací rozhraní (API) nebo služba, která Klient chce použít jménem Vlastník zdroje'A. - Přesměrování URI:
Ten odkaz Autorizační server přesměruje Vlastník zdroje„a po udělení povolení Klient'na. Někdy se označuje jako „URL zpětného volání“. - typ odezvy:
Typ informací, které mají být přijaty Klient. Nejčastější typ odezvy'Ohm, to je kód Klient očekává, že obdrží Autorizační kód. - Rozsah:
Toto je podrobný popis oprávnění, která jsou vyžadována Klient'y, jako je přístup k datům nebo provádění určitých akcí. - Souhlas:
Autorizační server trvá Puškohledyvyžádáno Klient'om, a ptá se Vlastník zdroje'a, je připraven poskytnout Klient„mají příslušná oprávnění. - ID zákazníka:
Toto ID slouží k identifikaci Klient'a on Autorizační server'E. - Tajemství klienta:
Toto je pouze známé heslo Klienta Autorizační server'na. Umožňuje jim soukromě sdílet informace. - Autorizační kód:
Dočasný kód s krátkou dobou platnosti, který Klient poskytuje Autorizační server'y výměnou za přístup Token. - přístup Token:
Klíč, se kterým bude klient komunikovat zdrojový server'om. Jakýsi odznak nebo klíčová karta, která poskytuje Klient„mají oprávnění vyžadovat data nebo provádět akce na zdrojový serverje vaším jménem.
Poznámka: Někdy je autorizační server a server prostředků stejný server. V některých případech se však může jednat o různé servery, i když nepatří do stejné organizace. Autorizační server může být například službou třetí strany, které Resource Server důvěřuje.
Nyní, když jsme probrali základní koncepty OAuth 2.0, vraťme se k našemu příkladu a blíže se podíváme na to, co se děje v toku OAuth.
- Vy, Vlastník zdroje, chcete poskytovat službu Hrozná hříčka dne (Klienty) přístup k vašim kontaktům, aby mohly posílat pozvánky všem vašim přátelům.
- Klient přesměruje prohlížeč na stránku Autorizační server'a zahrnout do dotazu ID zákazníka, Přesměrování URI, typ odezvy a jeden nebo více Puškohledy (oprávnění), které potřebuje.
- Autorizační server vás ověří a v případě potřeby požádá o uživatelské jméno a heslo.
- Autorizační server zobrazí formulář Souhlas (potvrzení) se seznamem všech Puškohledyvyžádáno Klient'om. Souhlasíte nebo odmítáte.
- Autorizační server přesměruje vás na web Klient'a, pomocí Přesměrování URI s Autorizační kód (Autorizační kód).
- Klient komunikuje přímo s Autorizační server'ohm (obcházení prohlížeče Vlastník zdroje'a) a bezpečně odešle ID zákazníka, Tajemství klienta и Autorizační kód.
- Autorizační server zkontroluje data a odpoví přístup Token'om (přístupový token).
- Nyní Klient může použít přístup Token odeslat žádost zdrojový server získat seznam kontaktů.
ID klienta a tajný klíč
Dávno předtím, než jste společnosti Terrible Pun of the Day povolili přístup ke svým kontaktům, navázali klient a autorizační server pracovní vztah. Autorizační server vygeneroval ID klienta a tajný klíč klienta (někdy nazývané App ID и Tajemství aplikace) a zaslal je Klientovi k další interakci v rámci OAuth.
"- Ahoj! Rád bych s vámi spolupracoval! - Jasně, to není problém! Zde je vaše ID klienta a tajemství!“
Z názvu vyplývá, že tajný klíč klienta musí zůstat v tajnosti, aby jej znal pouze klient a autorizační server. Ostatně právě s jeho pomocí Autorizační server potvrzuje pravdu Klienta.
Ale to není vše... Přivítejte OpenID Connect!
OAuth 2.0 je určen pouze pro oprávnění - poskytovat přístup k datům a funkcím z jedné aplikace do druhé. (OIDC) je tenká vrstva nad OAuth 2.0, která přidává přihlašovací a profilové údaje uživatele, který je přihlášen k účtu. Organizace přihlašovací relace se často nazývá autentizace [ověření]a informace o uživateli přihlášeném do systému (tj Vlastník zdroje'e), — osobní data [identita]. Pokud autorizační server podporuje OIDC, je někdy označován jako poskytovatelem osobních údajů [poskytovatel identity]protože poskytuje Klient'mít informace o Vlastník zdroje'E.
OpenID Connect vám umožňuje implementovat scénáře, kdy lze jediné přihlášení použít ve více aplikacích – tento přístup je také známý jako jediné přihlášení (SSO). Aplikace může například podporovat integraci SSO se sociálními sítěmi, jako je Facebook nebo Twitter, což uživatelům umožňuje používat účet, který již mají a který preferují používat.
Tok (tok) OpenID Connect vypadá stejně jako v případě OAuth. Jediný rozdíl je v tom, že v primárním požadavku je použit konkrétní rozsah openid,-A Klient nakonec dostane jako přístup TokenA ID Token.
Stejně jako v toku OAuth přístup Token v OpenID Connect je to nějaká hodnota, která není jasná Klient'na. Z pohledu Klient'Á přístup Token představuje řetězec znaků, který je předán spolu s každým požadavkem zdrojový server'y, který určuje, zda je token platný. ID Token představuje úplně jinou věc.
ID Token je JWT
ID Token je speciálně formátovaný řetězec znaků známý jako JSON Web Token nebo JWT (někdy se tokeny JWT vyslovují jako "jots"). Vnějším pozorovatelům může JWT připadat jako nesrozumitelný blábol, ale Klient může z JWT extrahovat různé informace, jako je ID, uživatelské jméno, čas přihlášení, datum vypršení platnosti ID Token'a, přítomnost pokusů o zasahování do JWT. Data uvnitř ID Token'a jsou nazývány aplikací [nároky].
V případě OIDC existuje také standardní způsob, kterým Klient může požadovat dodatečné informace o osobě [identita] z Autorizační server'a, například pomocí e-mailové adresy přístup Token.
Další informace o OAuth a OIDC
Stručně jsme tedy zhodnotili, jak funguje OAuth a OIDC. Jste připraveni kopat hlouběji? Zde jsou další zdroje, které vám pomohou dozvědět se více o OAuth 2.0 a OpenID Connect:
Jako vždy klidně komentujte. Chcete-li být informováni o našich nejnovějších zprávách, přihlaste se k odběru и Okta pro vývojáře!
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com