Jegyzet. ford.: Ez a nagyszerű Okta cikke az OAuth és az OIDC (OpenID Connect) működését mutatja be egyszerűen és érthető módon. Ez a tudás hasznos lesz a fejlesztőknek, rendszergazdáknak, sőt a népszerű webalkalmazások "rendszeres felhasználóinak" is, amelyek nagy valószínűséggel bizalmas adatokat is cserélnek más szolgáltatásokkal.
Az internet kőkorszakában könnyű volt megosztani az információkat a szolgáltatások között. Egyszerűen megadta bejelentkezési nevét és jelszavát az egyik szolgáltatásból a másikba, így belépett a fiókjába, és megkapta a szükséges információkat.
– Add ide a bankszámládat. „Ígérjük, hogy a jelszóval és a pénzzel minden rendben lesz. Ez őszinte, őszinte!" *hee hee*
Borzalom! Soha senki ne követelje meg a felhasználótól, hogy ossza meg felhasználónevét és jelszavát, hitelesítő adatok, másik szolgáltatással. Nincs garancia arra, hogy a szolgáltatás mögött álló szervezet biztonságban tartja az adatokat, és nem gyűjt a szükségesnél több személyes információt. Lehet, hogy őrülten hangzik, de egyes alkalmazások még mindig ezt a gyakorlatot használják!
Ma egyetlen szabvány létezik, amely lehetővé teszi, hogy egy szolgáltatás biztonságosan használja egy másik adatait. Sajnos az ilyen szabványok sok zsargont és kifejezést használnak, ami megnehezíti a megértést. Ennek az anyagnak az a célja, hogy egyszerű illusztrációk segítségével elmagyarázza, hogyan működnek (Azt hiszi, hogy a rajzaim hasonlítanak a gyerekek festésére? Na jó!).
Ez az útmutató egyébként videó formátumban is elérhető:
Hölgyeim és uraim, üdvözlöm: OAuth 2.0
egy biztonsági szabvány, amely lehetővé teszi, hogy egy alkalmazás engedélyt szerezzen egy másik alkalmazás információihoz való hozzáféréshez. Az engedély kiadásának lépéseinek sorrendje [engedély] (vagy beleegyezés [beleegyezés]) gyakran hívnak felhatalmazást [felhatalmazás] vagy delegált felhatalmazás [átruházott felhatalmazás]. Ezzel a szabvánnyal lehetővé teszi egy alkalmazás számára, hogy az Ön nevében adatokat olvasson vagy egy másik alkalmazás funkcióit használja anélkül, hogy megadná a jelszavát. Osztály!
Tegyük fel például, hogy felfedez egy "A nap szerencsétlen szójátéka" nevű webhelyet. [A nap szörnyű szójátéka] és úgy döntött, hogy regisztrál rá, hogy napi szójátékokat kapjon SMS-ek formájában a telefonon. Nagyon tetszett az oldal, és úgy döntött, hogy megosztja barátaival. Végül is mindenki szereti a hátborzongató szójátékokat, igaz?
„A nap szerencsétlen szójátéka: Hallottál arról a fickóról, aki elvesztette teste bal felét? Most mindig igaza van!” (hozzávetőleges fordítás, mert az eredetinek megvan a maga szójátéka - kb. ford.)
Nyilvánvaló, hogy a névjegyzékben szereplő személyeknek nem lehet írni. És ha egy kicsit is olyan vagy, mint én, akkor mindent megtesz, hogy elkerüld a felesleges munkát. Szerencsére a Terrible Pun of the Day önmagában is meghívhatja az összes barátját! Ehhez csak meg kell nyitnia a hozzáférést a kapcsolattartók e-mailjéhez – maga a webhely küldi el nekik a meghívókat (OAuth-szabályok)!
„Mindenki szereti a szójátékokat! - Már bejelentkezve? „Szeretné engedélyezni, hogy a Terrible Pun of the Day webhely hozzáférjen a névjegyzékéhez? - Köszönöm! Ezentúl minden nap emlékeztetőt küldünk mindenkinek, akit ismer, az idők végezetéig! Te vagy a legjobb barát!"
- Válassza ki e-mail szolgáltatását.
- Ha szükséges, nyissa meg a levelezési webhelyet, és jelentkezzen be fiókjába.
- Adjon engedélyt a nap szörnyű szójátékának, hogy hozzáférjen a névjegyeihez.
- Térjen vissza a Terrible Pun of the Day oldalára.
Ha meggondolja magát, az OAuth-ot használó alkalmazások is lehetőséget nyújtanak a hozzáférés visszavonására. Ha úgy dönt, hogy többé nem szeretné megosztani kapcsolatait a nap szörnyű szójátékával, felkeresheti a levelezőoldalt, és eltávolíthatja a szójáték webhelyet az engedélyezett alkalmazások listájáról.
OAuth Flow
Épp most mentünk keresztül, amit általában ún folyam [folyam] OAuth. Példánkban ez a folyamat látható lépésekből, valamint több láthatatlan lépésből áll, amelyek során két szolgáltatás biztonságos információcserében állapodik meg. Az előző Terrible Pun of the Day példa a legáltalánosabb OAuth 2.0-s folyamatot használja, amelyet „engedélyezési kódként” ismertünk. ["engedélyezési kód" folyamat].
Mielőtt belemerülnénk az OAuth működésének részleteibe, beszéljünk néhány kifejezés jelentéséről:
- Erőforrás-tulajdonos:
Ez te vagy! Ön birtokolja hitelesítési adatait, adatait, és Ön irányítja a fiókjaival kapcsolatos összes tevékenységet. - Vásárló:
Egy alkalmazás (például a Terrible Pun of the Day szolgáltatás), amely bizonyos műveleteket szeretne elérni vagy végrehajtani a felhasználó nevében Erőforrás-tulajdonos'а. - Engedélyező szerver:
Az alkalmazás, amely tudja Erőforrás-tulajdonos'a és amelyben u Erőforrás-tulajdonos'már van fiókja. - erőforrás szerver:
Alkalmazásprogramozási felület (API) vagy szolgáltatás, amely Vásárló nevében akarja használni Erőforrás-tulajdonos'а. - Átirányítási URI:
A link, ami Engedélyező szerver átirányítja Erőforrás-tulajdonos„és az engedély megadása után Vásárló'nál nél. Néha „visszahívási URL-nek” is nevezik. - Válasz típusa:
A várhatóan beérkező információ típusa Vásárló. A leggyakrabban Válasz típusa'ohm a kód, vagyis Vásárló elvárja, hogy megkapja megerősítő kód. - Kör:
Ez a szükséges engedélyek részletes leírása Vásárló'y, mint például az adatokhoz való hozzáférés vagy bizonyos műveletek végrehajtása. - Beleegyezés:
Engedélyező szerver svájcisapka Scopeskérte Vásárló'om, és megkérdezi Erőforrás-tulajdonos'a, kész-e ellátni Vásárló'rendelkezik a megfelelő jogosultságokkal. - ügyfél-azonosító:
Ez az azonosító az azonosításra szolgál Vásárló'a bekapcsolva Engedélyező szerver'e. - Ügyféltitok:
Ez az a jelszó, ami csak ismert Vásárló'u és Engedélyező szerver'nál nél. Lehetővé teszi számukra az információk privát megosztását. - megerősítő kód:
Rövid érvényességi idejű ideiglenes kód, amely Vásárló biztosítja Engedélyező szerver'y cserébe Access Token. - Access Token:
A kulcs, amellyel az ügyfél kommunikálni fog erőforrás szerver'om. Egyfajta jelvény vagy kulcskártya, amely biztosítja Vásárló„engedélye van adatok kérésére vagy műveletek végrehajtására erőforrás szerveraz ön nevében.
Megjegyzés: Néha az engedélyezési kiszolgáló és az erőforrás-kiszolgáló ugyanaz a kiszolgáló. Bizonyos esetekben azonban ezek különböző szerverek lehetnek, még akkor is, ha nem tartoznak ugyanahhoz a szervezethez. Például az engedélyezési kiszolgáló lehet egy harmadik féltől származó szolgáltatás, amelyben az erőforrás-kiszolgáló megbízik.
Most, hogy áttekintettük az OAuth 2.0 alapfogalmait, térjünk vissza példánkhoz, és nézzük meg közelebbről, mi történik az OAuth-folyamatban.
- Ön, Erőforrás-tulajdonos, a nap szörnyű szójátékát szeretné nyújtani (Vásárlóy) hozzáférés a névjegyeihez, hogy meghívókat küldhessenek az összes barátjának.
- Vásárló átirányítja a böngészőt az oldalra Engedélyező szerver'a és szerepeljen a lekérdezésben ügyfél-azonosító, Átirányítási URI, Válasz típusa és egy vagy több Scopes (engedélyek) kell hozzá.
- Engedélyező szerver ellenőrzi Önt, szükség esetén felhasználónevet és jelszót kér.
- Engedélyező szerver űrlapot jelenít meg Beleegyezés (megerősítések) az összes listával Scopeskérte Vásárló'om. Egyetért vagy elutasít.
- Engedélyező szerver átirányítja az oldalra Vásárló'a, használ Átirányítási URI -val megerősítő kód (megerősítő kód).
- Vásárló közvetlenül kommunikál vele Engedélyező szerver'ohm (a böngésző megkerülésével Erőforrás-tulajdonos'a) és biztonságosan elküldi ügyfél-azonosító, Ügyféltitok и megerősítő kód.
- Engedélyező szerver ellenőrzi az adatokat és azzal válaszol Access Token'om (hozzáférési token).
- Most Vásárló lehet használni Access Token címre kérést küldeni erőforrás szerver hogy megkapja a névjegyzéket.
Ügyfélazonosító és titkos
Jóval azelőtt, hogy engedélyezte volna a Nap szörnyű szójátékának, hogy hozzáférjen a névjegyeihez, az ügyfél és a jogosultságkiszolgáló munkakapcsolatot létesített. Az engedélyezési szerver létrehozta az ügyfél-azonosítót és az ügyféltitkot (néha ún App ID и App Secret), és elküldte őket az Ügyfélnek további interakció céljából az OAuth-on belül.
"- Helló! Szeretnék veled dolgozni! - Persze, nem probléma! Itt van az Ön ügyfél-azonosítója és titka!”
A név azt sugallja, hogy az Ügyféltitkot titokban kell tartani, hogy azt csak az Ügyfél és a jogosultságkiszolgáló ismerje. Végtére is, az Engedélyező Szerver az ő segítségével erősíti meg az Ügyfél igazát.
De ez még nem minden... Üdvözlöm az OpenID Connectet!
Az OAuth 2.0 csak erre készült engedélyezés - adatokhoz és funkciókhoz való hozzáférés biztosítása egyik alkalmazásból a másikba. (OIDC) egy vékony réteg az OAuth 2.0 tetején, amely hozzáadja a fiókba bejelentkezett felhasználó bejelentkezési és profiladatait. A bejelentkezési munkamenet megszervezését gyakran úgy emlegetik hitelesítés [hitelesítés]és információkat a rendszerbe bejelentkezett felhasználóról (pl Erőforrás-tulajdonos'e), — személyes adatok [identitás]. Ha az engedélyezési kiszolgáló támogatja az OIDC-t, akkor néha úgy emlegetik személyes adatok szolgáltatója [identitásszolgáltató]mert biztosítja Vásárló'információja van róla Erőforrás-tulajdonos'e.
Az OpenID Connect lehetővé teszi olyan forgatókönyvek megvalósítását, ahol egyetlen bejelentkezés több alkalmazásban is használható – ez a megközelítés más néven egyszeri bejelentkezés (SSO). Például egy alkalmazás támogathatja az egyszeri bejelentkezést az olyan közösségi hálózatokkal, mint a Facebook vagy a Twitter, lehetővé téve a felhasználók számára, hogy olyan fiókot használjanak, amellyel már rendelkeznek, és amelyet szívesen használnak.
A folyamat (folyamat) OpenID Connect ugyanúgy néz ki, mint az OAuth esetében. Az egyetlen különbség az, hogy az elsődleges kérésben a használt konkrét hatókör az openid, - A Vásárló végül tetszik Access TokenÉs ID Token.
Csakúgy, mint az OAuth folyamatban, Access Token az OpenID Connectben ez egy olyan érték, amely nem egyértelmű Vásárló'nál nél. Szempontból Vásárló„A Access Token egy karaktersorozatot jelöl, amelyet minden egyes kéréssel együtt továbbítanak erőforrás szerver'y, amely meghatározza, hogy a token érvényes-e. ID Token egészen más.
Az ID Token egy JWT
ID Token egy speciálisan formázott karaktersorozat, amely JSON Web Token vagy JWT néven ismert (néha a JWT tokeneket "jots"-ként ejtik). A külső szemlélő számára a JWT érthetetlen halandzsának tűnhet, de Vásárló különböző információkat nyerhet ki a JWT-ből, például azonosítót, felhasználónevet, bejelentkezési időt, lejárati dátumot ID Token„a, a JWT beavatkozására tett kísérletek jelenléte. Adatok belül ID Token'a hívják alkalmazások [követelések].
Az OIDC esetében is létezik egy szabványos módszer, amellyel Vásárló további információkat kérhet az adott személyről [identitás] -tól Engedélyező szerver'a például egy e-mail cím Access Token.
További információ az OAuthról és az OIDC-ről
Tehát röviden áttekintettük az OAuth és az OIDC működését. Készen állsz a mélyebbre ásni? Íme további források, amelyek segítenek többet megtudni az OAuth 2.0-ról és az OpenID Connectről:
Mint mindig, nyugodtan írj véleményt. Ha szeretne értesülni a legfrissebb híreinkről, iratkozzon fel и Okta a fejlesztőknek!
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com