Megjegyzés fordítás.: Ebben a nagyszerű anyagban az Okta bemutatja az OAuth és az OIDC (OpenID Connect) működésének elveit egyszerűen és érthetően. Ezek az ismeretek hasznosak lesznek fejlesztők, rendszergazdák és akár a népszerű webalkalmazások "normál felhasználói" számára is, akik valószínűleg szintén érzékeny adatokat osztanak meg más szolgáltatásokkal.
Az internet "kőkorszakában" az információmegosztás más szolgáltatások között könnyű volt. Csak megadtad a felhasználónevedet és a jelszavadat az egyik szolgáltatásnak, hogy az beléphessen a fiókodba, és megszerezhesse a szükséges információkat.
"Add meg a banki adataidat." — "Ígérjük, hogy a jelszóval és a pénzzel minden rendben lesz. Tényleg, tisztán és őszintén!" *he-he*
Rettenetes! Senki és soha nem kérheti a felhasználótól, hogy ossza meg a felhasználónevével és jelszavával kapcsolatos adatait, egy másik szolgáltatással. Nincs garancia arra, hogy a mögötte álló szervezet biztonságosan tárolja az adatokat, és nem gyűjt össze több személyes információt, mint amire szüksége van. Ez talán őrültségnek tűnik, de egyes alkalmazások még mindig használják ezt a gyakorlatot!
Ma már létezik egy egységes szabvány, amely lehetővé teszi egy szolgáltatás számára, hogy biztonságosan felhasználja egy másik adatait. Sajnos az ilyen szabványok sok zsargonnyal és kifejezéssel élnek, ami megnehezíti a megértésüket. Ennek az anyagnak a célja, hogy egyszerű illusztrációkkal magyarázza el, hogyan működnek (Gondolod, hogy a rajzaim gyerekes firkálásra hasonlítanak? Hát, nem érdekel!).
Tudtad, hogy ez a útmutató videó formátumban is elérhető:
Hölgyeim és Uraim, bemutatjuk: OAuth 2.0
— ez a biztonsági szabvány lehetővé teszi, hogy egy alkalmazás engedélyt kérjen egy másik alkalmazásban lévő információkhoz való hozzáférésre. Az engedélyezés folyamatát [permission] SysWOW64 hozzájárulás [consent]) gyakran nevezik engedélyezésnek [authorization] vagy akár delegált engedélyezésnek [delegated authorization]. Ezzel a szabvánnyal lehetővé teszed, hogy egy alkalmazás a nevedben hozzáférhessen másik alkalmazás adataihoz vagy funkcióihoz, anélkül, hogy megosztanád vele a jelszavad. Szuper!
Vegyünk egy példát: képzelj el egy weboldalt "A nap borzalmas szójátéka" néven [Terrible Pun of the Day] és úgy döntött, hogy regisztrál, hogy minden nap szójátékokat kapjon szöveges üzenetek formájában a telefonjára. Nagyon tetszik Önnek a weboldal, és meg akarja osztani minden ismerősével. Hiszen a szörnyű szójátékokat mindenki szereti, nem igaz?
"A nap balszerencsés szójátéka: Hallottatok a srácról, aki elvesztette a testének bal felét? Most mindig jobbról jön!" (a fordítás körülbelüli, mivel az eredetiben saját szójáték van - megj. ford.)
Nyilvánvaló, hogy nem lehetséges mindenkinek a kapcsolati listán írni. És ha legalább egy kicsit hasonlít rád, akkor mindent meg fogsz tenni, hogy elkerüld a felesleges munkát. Szerencsére a Terrible Pun of the Day képes meghívni az összes barátodat! Ehhez csak annyit kell tenned, hogy megadod neki az elérhetőségek emailjéhez való hozzáférést - a weboldal automatikusan elküldi nekik a meghívókat (az OAuth menedzsel)!
"Mindenki szereti a szójátékokat! - Már bejelentkeztél? - Szeretnéd megadni a Terrible Pun of the Day weboldalnak a kapcsolatok listájához való hozzáférést? - Köszönjük! Mostantól minden nap emlékeztetőket fogunk küldeni mindenkinek, akit ismersz, örökké! Te vagy a legjobb barát!"
- Válaszd ki a levelezőszolgáltatásodat.
- Szükség esetén látogass el a levelezőweboldalra és lépj be a fiókodba.
- Engedélyezd a Terrible Pun of the Day weboldalnak, hogy hozzáférjen a kapcsolataidhoz.
- Térj vissza a Terrible Pun of the Day weboldalra.
Ha meggondolnád magad, az OAuth-t használó alkalmazások általában kínálnak módot a hozzáférés visszavonására. Ha úgy döntesz, hogy többé nem szeretnéd megosztani a kapcsolataidat a Terrible Pun of the Day-vel, látogass el a levelezőweboldalra és távolítsd el a szójátékok weboldalát az engedélyezett alkalmazások listájából.
OAuth folyamat
Most egy olyan folyamaton mentünk keresztül, amit általában folyamnak [flow] OAuth néven ismernek. A példánkban ez a folyamat látható lépésekből, valamint néhány láthatatlan lépésből áll, amelyben két szolgáltatás megállapodik a biztonságos információcserében. Az előző példában a Terrible Pun of the Day a leggyakoribb OAuth 2.0 folyamatot használja, amelyet "engedélyezési kód folyamat" néven ismernek. [„authorization code” flow].
Mielőtt mélyebben belemerülnénk az OAuth működésébe, beszéljünk néhány kifejezés jelentéséről:
- Erőforrás-tulajdonos:
Ez te vagy! Te birtoklod a hitelesítő adataidat, az adataidat és te irányítod az összes olyan tevékenységet, amely a fiókjaiddal kapcsolatban elvégezhető. - Ügyfél:
Egy alkalmazás (például a Terrible Pun of the Day szolgáltatás), amely hozzáférést szeretne kérni vagy bizonyos műveleteket szeretne végrehajtani a nevében Erőforrás-tulajdonos‘a. - Hitelesítési szerver:
Egy alkalmazás, amely tudja Erőforrás-tulajdonos‘a és amellyel Erőforrás-tulajdonos‘a már rendelkezik egy fiókkal. - Erőforrás-szerver:
Alkalmazásprogramozási interfész (API) vagy szolgáltatás, amelyet Ügyfél szeretne igénybe venni a nevében Erőforrás-tulajdonos‘a. - Átirányítási URI:
A hivatkozás, amelyen Hitelesítési szerver átirányítja Erőforrás-tulajdonos‘a a hozzájárulás biztosítása után Ügyfél‘u. Néha visszatérő URL-nek (Callback URL) is nevezik. - Válasz típusa:
Az az információtípus, amelyet várakozással vár Ügyfél. A leggyakoribb Válasz típusa‘om egy kód, tehát Ügyfél számít arra, hogy kap Hitelesítési kód. - Hatókör:
Ez a részletes leírás a szükséges engedélyekről, amelyekre szüksége van Ügyfél‘u, mint például az adatokhoz való hozzáférés vagy bizonyos tevékenységek végrehajtása. - Hozzájárulás:
Hitelesítési szerver megkérdezi Scopes, amelyeket Ügyfél‘om kér, és megkérdezi Erőforrás-tulajdonos‘a, hogy hajlandó-e megadni Ügyfél‘u megfelelő engedélyeit. - Client ID:
Ez az az ID, amelyet a Ügyfél‘a azonosítására használnak Hitelesítési szerver‘e. - Kliens titok:
Ez egy jelszó, amely csak Ügyfél‘u és Hitelesítési szerver‘u számára ismert. Lehetővé teszi számukra, hogy titkos információt cseréljenek. - Hitelesítési kód:
Ideiglenes kód, amely rövid ideig érvényes, amelyet Ügyfél biztosít Hitelesítési szerver‘u cserél az Hozzáférési tokenre. - Hozzáférési tokenre:
Kulcs, amelyet az ügyfél használni fog a kapcsolatfelvételhez Erőforrás-szerver‘u. Ez egyfajta kitűző vagy kulcskártya, amely lehetővé teszi Ügyfél‘u számára, hogy adatokat kérjen vagy műveleteket hajtson végre a nevében az Erőforrás-szerver‘e.
Megjegyzés: néha a Hitelesítési szerver és az Erőforrás-szerver ugyanaz a szerver. Azonban egyes esetekben ezek különböző szerverek is lehetnek, amelyek még csak nem is tartoznak ugyanabba a szervezetbe. Például a Hitelesítési szerver lehet egy külső szolgáltatás, amelyet az Erőforrás-szerver megbízhatónak tart.
Most, hogy megismertük az OAuth 2.0 alapvető fogalmait, térjünk vissza példánkhoz, és nézzük meg részletesen, mi történik az OAuth folyamatában.
- Ön, Erőforrás-tulajdonos, szeretné biztosítani a Terrible Pun of the Day szolgáltatásnak (Ügyfél‘u) a hozzáférést a kapcsolataihoz, hogy az meghívót küldhessen minden barátjának.
- Ügyfél átirányítja a böngészőt a Hitelesítési szerver‘a oldalára, és a kérésbe beilleszti Client ID, Átirányítási URI, Válasz típusa és egy vagy több Scopes (engedély), amelyekre szüksége van.
- Hitelesítési szerver ellenőrzi az Ön azonosítását, szükség esetén kérve a felhasználónevet és jelszót.
- Hitelesítési szerver kibocsát egy Hozzájárulás (megerősítési) űrlapot, amely tartalmazza az összes Scopes, amelyet Ügyfél‘om kér.
- Hitelesítési szerver Ön elfogadja vagy megtagadja. Ügyfélátirányítja Önt a Átirányítási URI együtt a Hitelesítési kód ‘a webhelyére, az
- Ügyfél hitelesítési kód Hitelesítési szerverszerver közvetlenül kapcsolatba lép az Erőforrás-tulajdonos‘ommal (körbezárva a böngészőt) és biztonságosan küldi el. Client ID, Kliens titok és Hitelesítési kód.
- Hitelesítési szerver ellenőrzi az adatokat és válaszol Hozzáférési tokenre‘el (hozzáférési token).
- Most Ügyfél felhasználható Hozzáférési tokenre a kérés elküldésére Erőforrás-szerver a kapcsolatok listájának megszerzésére.
Ügyfél ID és Secret
Mielőtt engedélyezte volna a Terrible Pun of the Day hozzáférését a kapcsolatokhoz, az Ügyfél és az Engedélyezési Szerver együttműködést alakított ki. Az Engedélyezési Szerver generálta az Ügyfél ID-t és az Ügyfél Secret-et (néha ezeket hívják Alkalmazás ID és Alkalmazás Secret) és elküldte az Ügyfélnek további interakciókhoz az OAuth keretén belül.
„— Helló! Szeretnék veled dolgozni! — Nincs probléma! Itt vannak az Ügyfél ID-d és Secret-ed!”
A név arra utal, hogy az Ügyfél Secret-nek titokban kell maradnia, csak az Ügyfél és az Engedélyezési Szerver ismerheti. Hiszen az Engedélyezési Szerver éppen ezzel igazolja az Ügyfél valódiságát.
De ez még nem minden… Kérem, üdvözöljük az OpenID Connect-et!
Az OAuth 2.0-t kizárólag arra fejlesztették ki, engedélyezési — hogy hozzáférést biztosítson az adatokhoz és funkciókhoz egyik alkalmazástól a másikhoz. (OIDC) — ez egy vékony réteg az OAuth 2.0 fölött, amely a bejelentkezésről és a felhasználói profilról ad információt a bejelentkezett felhasználóról. A bejelentkezési ülések kezelését gyakran hitelesítésnek [authentication], a bejelentkezett felhasználó információi (pl. az Erőforrás-tulajdonos‘jéről) — személyes adatok [identity]. Ha az Engedélyezési Szerver támogatja az OIDC-t, akkor néha az személyes adatszolgáltatónak [identity provider]nevezik, mivel Ügyfél‘nak információt nyújt Erőforrás-tulajdonos‘e.
Az OpenID Connect lehetővé teszi, hogy egyetlen bejelentkezést használjunk több alkalmazásban — ezt a megközelítést egyesek úgy is ismerik, mint single sign-on (SSO). Például egy alkalmazás SSO integrációt támogathat 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 azt a fiókjukat használják, amely már megvan és amelyet előnyben részesítenek.
Az OpenID Connect folyamat (flow) ugyanúgy néz ki, mint az OAuth esetében. Az egyetlen különbség az, hogy az elsődleges kérésnél a használt konkrét scope — openid, — és végül megkapja az Ügyfél ID tokent. Hozzáférési tokenre, valamint Ugyanúgy, mint az OAuth folyamatában,.
az OpenID Connect esetében — ez egy érték, amely nem érthető Hozzáférési tokenre ‘nak. Az Ügyfél‘ szemszögéből Ügyfélez egy karakterláncot képvisel, amelyet minden kéréshez továbbítanak Hozzáférési tokenre ‘nak, és ő határozza meg, hogy a token érvényes-e. Erőforrás-szervervalami egészen más. Ugyanúgy, mint az OAuth folyamatában, Az ID token egy JWT
— ez egy különlegesen formázott karakterlánc, amelyet JSON Web Token-nek vagy JWT-nek neveznek
Ugyanúgy, mint az OAuth folyamatában, (néha a JWT-ket "jotsnak" ejtik) (a JWT tokent néha „jots”-nak hívják). A külső megfigyelők számára a JWT érthetetlennek tűnhet, de Ügyfél különféle információkat nyerhetünk ki a JWT-ből, például az ID-t, a felhasználó nevét, a bejelentkezés időpontját és a lejárati időt Ugyanúgy, mint az OAuth folyamatában,a JWT-be való beavatkozás kísérletét. Az adatok a Ugyanúgy, mint az OAuth folyamatában,belül találhatóak igények [claims].
OIDC esetén is létezik egy szabványos módszer, amellyel Ügyfél további információt kérhetünk a személyazonosságról [identity] tól Hitelesítési szerverpéldául e-mail címet, használva a Hozzáférési tokenre.
További információk az OAuth és OIDC kapcsolatban
Így röviden áttekintettük az OAuth és OIDC működésének alapelveit. Készen áll arra, hogy mélyebbre ásson? Íme néhány további forrás, amelyek segítenek többet megtudni az OAuth 2.0-ról és az OpenID Connect-ről:
Mint mindig, ne habozzon kommentálni. Hogy naprakészen követhesse legfrissebb újdonságainkat, iratkozzon fel a és Okta fejlesztői vállalatra!
Fejlesztési eszközök, amelyek Kubernetesben futnak
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
