OAuth (Open Authorization): a token-alapú internetes authorizáció működése

Mi az OAuth? Az internetes jogosultságkezelés alapköve

A modern digitális világban naponta számtalan online szolgáltatást veszünk igénybe. Ezek közül sok esetben szeretnénk, ha az egyik szolgáltatás hozzáférhetne a másikban tárolt adatainkhoz, anélkül, hogy a teljes hozzáférésünket vagy a felhasználónevünket és jelszavunkat megosztanánk. Gondoljunk csak arra, amikor egy harmadik féltől származó alkalmazással szeretnénk bejelentkezni Google-fiókunkba, vagy amikor egy fotószerkesztő alkalmazásnak engedélyezzük a Facebook-fotóink elérését. Pontosan erre a problémára kínál elegáns és biztonságos megoldást az OAuth (Open Authorization) protokoll.

Az OAuth egy nyílt szabvány a delegált jogosultságkezelésre. Ez azt jelenti, hogy lehetővé teszi egy felhasználó számára, hogy egy harmadik fél alkalmazásnak korlátozott hozzáférést biztosítson a védett erőforrásaihoz egy másik szolgáltatáson belül, anélkül, hogy a felhasználó megosztaná a teljes hitelesítő adatait (pl. felhasználónév és jelszó) az adott harmadik féllel. Lényegében egy digitális meghatalmazásról van szó, ahol a felhasználó felhatalmazza az egyik szolgáltatást, hogy a nevében járjon el egy másik szolgáltatásnál, de csak a szigorúan meghatározott kereteken belül.

Korábban, az OAuth megjelenése előtt, ha egy alkalmazásnak hozzá kellett férnie a felhasználó adataihoz egy másik szolgáltatásban, gyakran az volt az egyetlen megoldás, hogy a felhasználó megadta a felhasználónevét és jelszavát a harmadik fél alkalmazásnak. Ez rendkívül kockázatos volt, hiszen az alkalmazás így teljes hozzáférést kapott a fiókhoz, és bármikor visszaélhetett vele. Emellett, ha a felhasználó megváltoztatta a jelszavát, az alkalmazás hozzáférése azonnal megszűnt, és újra meg kellett volna adni a frissített adatokat.

Az OAuth forradalmasította az internetes jogosultságkezelést azáltal, hogy bevezette a token-alapú delegált authorizáció fogalmát, amely lehetővé teszi a felhasználók számára, hogy biztonságosan és kontrolláltan adjanak korlátozott hozzáférést adataikhoz, anélkül, hogy valaha is megosztanák jelszavaikat harmadik felekkel.

Az OAuth elsődleges célja tehát a felhasználói adatok védelme és a biztonságos, finomhangolt hozzáférés biztosítása. Nem az autentikációról szól elsősorban – bár az OpenID Connect (OIDC) kiegészítéssel ez is megoldható –, hanem a jogosultságok delegálásáról. Fontos különbséget tenni a hitelesítés (autentikáció) és a jogosultságkezelés (authorizáció) között. Az autentikáció az a folyamat, amikor egy rendszer meggyőződik arról, hogy ki vagy te (pl. felhasználónév és jelszó ellenőrzésével). Az authorizáció pedig az a folyamat, amikor eldöntik, hogy mit tehetsz az adott rendszerben, vagy milyen adatokhoz férhetsz hozzá, miután hitelesítetted magad.

Az OAuth protokoll a hozzáférési tokenek (access token) használatára épül. Ezek a tokenek lényegében kulcsok, amelyek korlátozott ideig és meghatározott hatókörön belül biztosítanak hozzáférést a védett erőforrásokhoz. A tokenek használatával a felhasználónak soha nem kell megosztania a jelszavát azzal az alkalmazással, amely az adatait szeretné elérni. Ezáltal drasztikusan csökken a biztonsági kockázat, és a felhasználó sokkal nagyobb kontrollal rendelkezik az adatai felett.

Az OAuth több verzióban létezik, de a legelterjedtebb és jelenleg standardnak számító változat az OAuth 2.0. Ez a verzió egy keretrendszer, amely rugalmasan alkalmazkodik különböző forgatókönyvekhez (webes alkalmazások, mobil alkalmazások, gépek közötti kommunikáció stb.), ellentétben az OAuth 1.0-val, amely sokkal szigorúbb és bonyolultabb volt a kriptográfiai aláírások miatt. Az OAuth 2.0 a HTTPS protokollra támaszkodik a kommunikáció titkosításához, ami jelentősen egyszerűsíti a megvalósítást és növeli a biztonságot.

Az OAuth 2.0 alapvető szereplői és fogalmai

Az OAuth 2.0 protokoll megértéséhez elengedhetetlen, hogy tisztában legyünk azokkal a kulcsfontosságú szereplőkkel és fogalmakkal, amelyek a rendszerben részt vesznek. Ezek a komponensek együttműködve biztosítják a biztonságos és delegált jogosultságkezelési folyamatot.

• Resource Owner (Erőforrás Tulajdonos):

  Ez a felhasználó, aki a védett erőforrások tulajdonosa, és aki engedélyt ad egy kliens alkalmazásnak az erőforrásaihoz való hozzáférésre. Ő az, aki a Google-fiókja vagy Facebook-profilja adatait birtokolja, és aki eldönti, hogy melyik alkalmazás férhet hozzá azokhoz az adatokhoz. Az erőforrás tulajdonos az, aki interakcióba lép az Authorizációs Szerverrel, hogy engedélyezze a hozzáférést.

• Client (Kliens Alkalmazás):

  Ez az az alkalmazás, amely a felhasználó nevében hozzáférést szeretne kapni a védett erőforrásokhoz. Lehet ez egy webes alkalmazás (pl. egy online fotószerkesztő), egy mobilalkalmazás (pl. egy naptár app), egy asztali alkalmazás, vagy akár egy másik szerver-oldali alkalmazás. A kliens alkalmazásnak előzetesen regisztrálnia kell magát az Authorizációs Szervernél, hogy egyedi azonosítót (Client ID) és gyakran egy titkot (Client Secret) kapjon.

• Authorization Server (Authorizációs Szerver):

  Ez a szerver az, amelyik hitelesíti az erőforrás tulajdonost, és engedélyt kér tőle a kliens alkalmazás nevében. Ha az erőforrás tulajdonos megadja az engedélyt, az Authorizációs Szerver kibocsát egy hozzáférési tokent (access token) a kliens alkalmazás számára. Ez a szerver felelős a felhasználó bejelentkeztetéséért és a hozzájárulásának kezeléséért. Például, amikor a Google-fiókoddal jelentkezel be egy harmadik féltől származó alkalmazásba, a Google szerverei töltik be az Authorizációs Szerver szerepét.

• Resource Server (Erőforrás Szerver):

  Ez a szerver tárolja a felhasználó védett erőforrásait (pl. fotók, e-mailek, profiladatok) és kezeli az azokhoz való hozzáférést. Miután a kliens alkalmazás megkapta a hozzáférési tokent az Authorizációs Szervertől, ezt a tokent mutatja be az Erőforrás Szervernek, hogy hozzáférjen a kívánt adatokhoz. Az Erőforrás Szerver ellenőrzi a token érvényességét és a hozzá tartozó jogosultságokat, majd ennek megfelelően biztosít vagy tagad meg hozzáférést. Az Authorizációs Szerver és az Erőforrás Szerver gyakran ugyanazon szolgáltató (pl. Google, Facebook) része, de funkcionálisan elkülönülnek.

Kiegészítő fogalmak az OAuth 2.0-ban:

• Grant Type (Engedélyezési Típus):

  Ez az a módszer, amellyel a kliens alkalmazás hozzáférési tokent szerez az Authorizációs Szervertől. Az OAuth 2.0 több különböző engedélyezési típust definiál, amelyek különböző forgatókönyvekhez és biztonsági követelményekhez igazodnak. A leggyakoribbak az Authorization Code, Implicit, Resource Owner Password Credentials és Client Credentials típusok. Az adott alkalmazás és a biztonsági igények alapján választják ki a megfelelő típust.

• Access Token (Hozzáférési Token):

  Ez egy rövid élettartamú, titkosított vagy aláírt karakterlánc, amelyet az Authorizációs Szerver bocsát ki a kliens alkalmazás számára. Ez a token a felhasználó nevében biztosít korlátozott hozzáférést a védett erőforrásokhoz az Erőforrás Szerveren. A token tartalmazza a hozzáférés hatókörét és érvényességi idejét. Amikor a kliens alkalmazás hozzáfér egy védett erőforráshoz, ezt a tokent küldi el az HTTP kérés fejlécében (általában az Authorization: Bearer [token] formátumban).

• Refresh Token (Frissítő Token):

  Ez egy hosszú élettartamú token, amelyet a hozzáférési token mellett bocsát ki az Authorizációs Szerver. Célja, hogy a kliens alkalmazás új hozzáférési tokent kérhessen, miután a régi lejárt, anélkül, hogy a felhasználónak újra hitelesítenie kellene magát. Ez javítja a felhasználói élményt, miközben fenntartja a biztonságot, mivel a frissítő tokent általában biztonságosan, szerver-oldalon tárolják, és csak az Authorizációs Szerverrel való kommunikációra használják.

• Scope (Hatókör):

  A hatókörök definiálják azt a specifikus jogosultsági szintet, amelyet a kliens alkalmazás kér a védett erőforrásokhoz. Például, egy alkalmazás kérheti a „csak olvasható” hozzáférést a felhasználó profiljához (profile:read) vagy az e-mailekhez való írási jogot (email:send). Az erőforrás tulajdonosnak jóvá kell hagynia ezeket a kért hatóköröket az Authorizációs Szerveren keresztül. Ez biztosítja a finomhangolt jogosultságkezelést, megakadályozva, hogy egy alkalmazás a szükségesnél nagyobb hozzáférést kapjon.

• Redirect URI (Átirányítási URI):

  Ez egy előre regisztrált URL, ahová az Authorizációs Szerver visszaküldi a felhasználót (és az engedélyezési kódot vagy tokent) az engedélyezési folyamat befejezése után. Az átirányítási URI-k szigorú ellenőrzése kulcsfontosságú a biztonság szempontjából, mivel megakadályozza a jogosulatlan átirányítási támadásokat.

Ezeknek a fogalmaknak a megértése alapvető ahhoz, hogy átlássuk, hogyan működik az OAuth, és hogyan biztosítja a biztonságos és delegált hozzáférést a felhasználói adatokhoz a különböző online szolgáltatások között.

Az OAuth 2.0 protokoll működése lépésről lépésre – Az általános folyamat

Az OAuth 2.0 keretrendszer, és mint ilyen, különböző „flow”-kat, azaz engedélyezési típusokat támogat. Azonban van egy alapvető, általános folyamat, amely a legtöbb grant típus magját képezi, különösen az Authorization Code Grant esetében, amely a legbiztonságosabb és leggyakrabban használt. Nézzük meg, hogyan zajlik ez a delegált authorizációs folyamat a gyakorlatban.

1. Kliens regisztrációja (Client Registration):

   Mielőtt egy kliens alkalmazás egyáltalán elindíthatná az OAuth folyamatot, regisztrálnia kell magát az Authorizációs Szervernél (pl. Google, Facebook fejlesztői konzolján). Ez a regisztráció során az alkalmazás kap egy Client ID-t (kliens azonosító), amely egy nyilvános azonosító, és gyakran egy Client Secret-et (kliens titok) is, amely egy bizalmas kulcs, amelyet csak a szerver-oldali alkalmazások tárolhatnak biztonságosan. Ezen felül az alkalmazásnak meg kell adnia az átirányítási URI-kat (Redirect URI), amelyekre az Authorizációs Szerver visszaküldi a válaszokat. Ez a lépés alapvető a biztonság szempontjából, mivel az Authorizációs Szerver csak ezekre az előre regisztrált URL-ekre küldhet adatokat, megelőzve a hamisított átirányítási támadásokat.

2. Felhasználói engedélyezés kérése (Authorization Request):

   Amikor a felhasználó szeretne bejelentkezni egy kliens alkalmazásba egy külső szolgáltatással (pl. „Bejelentkezés Google-lel”), vagy az alkalmazás hozzáférést kér a felhasználó adataihoz, a kliens alkalmazás átirányítja a felhasználó böngészőjét az Authorizációs Szerverre. Ez az átirányítás egy speciális URL-re történik, amely tartalmazza a Client ID-t, a kért hatóköröket (scope-okat), az átirányítási URI-t, és egy state paramétert a CSRF (Cross-Site Request Forgery) támadások megelőzésére.

   Például egy URL így nézhet ki:

   https://accounts.google.com/o/oauth2/v2/auth?
           response_type=code&
           client_id=YOUR_CLIENT_ID&
           scope=openid%20profile%20email&
           redirect_uri=YOUR_REDIRECT_URI&
           state=RANDOM_STRING

3. Felhasználó hitelesítése és jóváhagyása (User Authentication & Consent):

   Az Authorizációs Szerver fogadja az átirányítást, és először is hitelesíti az erőforrás tulajdonost (a felhasználót). Ha a felhasználó nincs bejelentkezve, megkéri, hogy tegye meg. Ezután az Authorizációs Szerver megjelenít egy hozzájárulási képernyőt a felhasználó számára, amelyen fel van sorolva, hogy a kliens alkalmazás milyen adatokhoz (scope-okhoz) kér hozzáférést. A felhasználó itt döntheti el, hogy engedélyezi-e ezt a hozzáférést vagy sem. Ha a felhasználó jóváhagyja, az Authorizációs Szerver folytatja a folyamatot. Ha elutasítja, a folyamat megszakad.

4. Engedélyezési kód kibocsátása (Authorization Code Grant – Specifikus lépés):

   Ha a felhasználó jóváhagyta a hozzáférést, az Authorizációs Szerver visszaküldi a felhasználó böngészőjét a kliens alkalmazás előre regisztrált átirányítási URI-jára. Az URL tartalmazni fog egy engedélyezési kódot (authorization code) és a korábban küldött state paramétert. Ez az engedélyezési kód egy rövid élettartamú, egyszer használatos kód, amelyet a kliens alkalmazás szerver-oldalon használ fel a hozzáférési token megszerzéséhez. Fontos, hogy ez a kód a böngésző URL-jében utazik, de önmagában nem ad hozzáférést az erőforrásokhoz.

   YOUR_REDIRECT_URI?code=AUTHORIZATION_CODE&state=RANDOM_STRING

5. Hozzáférési token cseréje (Token Exchange):

   A kliens alkalmazás szerver-oldali része megkapja az engedélyezési kódot az átirányítási URI-ról. Ezután a kliens alkalmazás szerver-oldala egy közvetlen POST kérést küld az Authorizációs Szerver token végpontjára. Ez a kérés tartalmazza az engedélyezési kódot, a Client ID-t és a Client Secret-et (ha van), valamint az átirányítási URI-t. Mivel ez egy közvetlen szerver-szerver kommunikáció, a Client Secret biztonságosan továbbítható.

   Az Authorizációs Szerver ellenőrzi a kapott adatokat: az engedélyezési kódot, a Client ID-t és a Client Secret-et. Ha minden érvényes, az Authorizációs Szerver kibocsát egy hozzáférési tokent (access token), és opcionálisan egy frissítő tokent (refresh token). Ezeket a tokeneket JSON formátumban küldi vissza a kliens alkalmazásnak.

6. Erőforrás elérése a token segítségével (Accessing Protected Resources):

   Miután a kliens alkalmazás megkapta a hozzáférési tokent, most már hozzáférhet a védett erőforrásokhoz az Erőforrás Szerveren. Minden kéréshez, amelyet a kliens az Erőforrás Szervernek küld, mellékelnie kell a hozzáférési tokent az HTTP Authorization fejlécében, általában a „Bearer” séma használatával:

   Authorization: Bearer YOUR_ACCESS_TOKEN

   Az Erőforrás Szerver ellenőrzi a token érvényességét (pl. lejárt-e, megfelelő hatókörrel rendelkezik-e), és ha érvényes, akkor válaszol a kérésre, és biztosítja a hozzáférést a kért erőforrásokhoz.

7. Token érvényesítése és frissítése (Token Expiration & Refresh):

   A hozzáférési tokenek általában rövid élettartamúak (pl. 1 óra). Amikor a token lejár, a kliens alkalmazás már nem tudja használni az Erőforrás Szerverrel való kommunikációhoz. Ekkor jön képbe a frissítő token. Ha a kliens rendelkezik frissítő tokennel, elküldheti azt az Authorizációs Szervernek egy speciális kérésben, hogy új hozzáférési tokent kapjon anélkül, hogy a felhasználónak újra be kellene jelentkeznie. Ez a folyamat megismételhető, amíg a frissítő token is le nem jár, vagy a felhasználó vissza nem vonja az engedélyt.

Ez az általános folyamat az OAuth 2.0 alapja. A különböző Grant Típusok (flow-k) lényegében ennek a folyamatnak a variációi, amelyek a 4. és 5. lépésben térnek el, attól függően, hogy milyen típusú kliens alkalmazásról van szó, és milyen biztonsági megfontolások érvényesülnek.

Különböző Grant Típusok (Flow-k) részletes bemutatása

Az OAuth 2.0 rugalmasságát az adja, hogy nem egyetlen, merev protokoll, hanem egy keretrendszer, amely különböző „grant type”-okat, azaz engedélyezési típusokat definiál. Ezek a típusok optimalizálva vannak különböző kliens alkalmazás-típusok és biztonsági követelmények számára. Nézzük meg a legfontosabbakat részletesen.

1. Authorization Code Grant (Engedélyezési Kód Típus)

Az Authorization Code Grant a leggyakrabban használt és a legbiztonságosabb OAuth 2.0 flow, különösen szerver-oldali webes alkalmazások esetében. Ez a típus kihasználja a szerver-szerver kommunikáció biztonságát, hogy a hozzáférési token soha ne legyen kitéve a felhasználó böngészőjének vagy a kliens oldali szkripteknek.

Mikor használjuk?

• Webes alkalmazások (különösen azok, amelyek rendelkeznek biztonságos szerver-oldali komponenssel).
• Minden olyan esetben, ahol a legmagasabb szintű biztonságra van szükség a tokenek szempontjából.

Részletes lépések:

1. Kliens kérés indítása: A felhasználó a kliens webalkalmazásban rákattint egy „Bejelentkezés Google-lel” vagy hasonló gombra. A kliens alkalmazás átirányítja a felhasználó böngészőjét az Authorizációs Szerverre a /authorize végpontjára. A kérés tartalmazza a client_id-t, a response_type=code paramétert, a kért scope-okat, a redirect_uri-t és egy egyedi state paramétert.

   GET /authorize?response_type=code&client_id=YOUR_CLIENT_ID&scope=email%20profile&redirect_uri=YOUR_REDIRECT_URI&state=RANDOM_STATE HTTP/1.1
   Host: auth.example.com

2. Felhasználó hitelesítése és hozzájárulása: Az Authorizációs Szerver hitelesíti a felhasználót (ha szükséges), és megjeleníti a hozzájárulási képernyőt, ahol a felhasználó jóváhagyja vagy elutasítja a kért jogosultságokat.
3. Engedélyezési kód visszaküldése: Ha a felhasználó jóváhagyja, az Authorizációs Szerver visszairányítja a felhasználó böngészőjét a kliens alkalmazás előre regisztrált redirect_uri-jára. Az URL tartalmazza az authorization code-ot és a state paramétert.

   HTTP/1.1 302 Found
   Location: YOUR_REDIRECT_URI?code=AUTHORIZATION_CODE&state=RANDOM_STATE

   A kliens alkalmazás szerver-oldali része ellenőrzi a state paramétert a CSRF támadások elkerülése érdekében.

4. Hozzáférési token kérése (szerver-szerver kommunikáció): A kliens alkalmazás szerver-oldala (és ez a kulcsfontosságú biztonsági lépés) most egy közvetlen POST kérést küld az Authorizációs Szerver /token végpontjára. Ez a kérés tartalmazza az authorization code-ot, a client_id-t, a client_secret-et (amelyet a kliens szerver-oldalán biztonságosan tárolnak), és a redirect_uri-t.

   POST /token HTTP/1.1
   Host: auth.example.com
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&
   code=AUTHORIZATION_CODE&
   redirect_uri=YOUR_REDIRECT_URI&
   client_id=YOUR_CLIENT_ID&
   client_secret=YOUR_CLIENT_SECRET

5. Tokenek kibocsátása: Az Authorizációs Szerver ellenőrzi az engedélyezési kódot és a kliens hitelesítő adatait. Ha minden érvényes, egy JSON választ küld vissza, amely tartalmazza az access token-t, a refresh token-t (opcionálisan), a token élettartamát (expires_in), a token típusát (token_type, pl. „Bearer”), és a kért scope-okat.

   HTTP/1.1 200 OK
   Content-Type: application/json
   
   {
       "access_token": "YOUR_ACCESS_TOKEN",
       "token_type": "Bearer",
       "expires_in": 3600,
       "refresh_token": "YOUR_REFRESH_TOKEN",
       "scope": "email profile"
   }

   A hozzáférési token soha nem kerül a felhasználó böngészőjébe, ami jelentősen növeli a biztonságot.

6. Erőforrás elérése: A kliens alkalmazás a megszerzett access token-nel küld kéréseket az Erőforrás Szervernek.

PKCE kiterjesztés (Proof Key for Code Exchange)

Az Authorization Code Grant még biztonságosabbá tehető a PKCE (Proof Key for Code Exchange) kiterjesztéssel. Ezt eredetileg mobil- és asztali alkalmazások számára fejlesztették ki, ahol a kliens titok (Client Secret) nem tárolható biztonságosan, de ma már webes alkalmazásokban is erősen ajánlott. A PKCE megakadályozza az „authorization code injection” támadásokat, ahol egy rosszindulatú alkalmazás lehallgathatja az engedélyezési kódot, és ellophatja azt.

A PKCE bevezeti a code_verifier és code_challenge fogalmát:

• code_verifier: Egy véletlenszerűen generált, kriptográfiailag erős string, amelyet a kliens generál minden egyes engedélyezési kéréshez. Ez a string biztonságosan tárolódik a kliens oldalon.
• code_challenge: A code_verifier kriptográfiai hash-e (általában SHA256), amelyet az engedélyezési kérés során küld el a kliens az Authorizációs Szervernek.

A folyamat a 4. lépésnél egészül ki:

4. Hozzáférési token kérése (PKCE-vel): Amikor a kliens alkalmazás elküldi a POST kérést az Authorizációs Szerver /token végpontjára, az engedélyezési kód és az esetleges Client Secret mellett elküldi a code_verifier-t is. Az Authorizációs Szerver ekkor újra generálja a code_challenge-et a kapott code_verifier-ből, és összehasonlítja azt azzal a code_challenge-el, amelyet az eredeti engedélyezési kérés során kapott. Ha a kettő egyezik, a kérés érvényesnek tekinthető. Ez biztosítja, hogy csak az az alkalmazás tudja beváltani az engedélyezési kódot, amelyik az eredeti kérést indította.

   POST /token HTTP/1.1
   Host: auth.example.com
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&
   code=AUTHORIZATION_CODE&
   redirect_uri=YOUR_REDIRECT_URI&
   client_id=YOUR_CLIENT_ID&
   code_verifier=YOUR_CODE_VERIFIER

A PKCE használata erősen ajánlott minden Authorization Code Grant implementációban, különösen a „public client”-ek (azaz olyan kliensek, amelyek nem képesek biztonságosan tárolni egy Client Secret-et, mint pl. böngészőben futó SPA-k vagy mobilalkalmazások) esetében.

2. Implicit Grant (Implicit Típus)

Az Implicit Grant egy egyszerűsített flow volt, amelyet eredetileg kliens-oldali webes alkalmazások (pl. Single Page Applications – SPA) vagy mobilalkalmazások számára terveztek, ahol nincs szerver-oldali komponens, amely biztonságosan tárolhatná a Client Secret-et vagy végrehajthatná a szerver-szerver token cserét. Azonban biztonsági okokból az OAuth 2.1-ben elavulttá vált, és helyette az Authorization Code Grant PKCE kiterjesztéssel való használata javasolt.

Mikor használták?

• Kliens-oldali webes alkalmazások (SPA), ahol a token közvetlenül a böngészőben keletkezett.
• Mobilalkalmazások (bár itt is a PKCE-s Authorization Code lett az ajánlott).

Részletes lépések:

1. Kliens kérés indítása: A kliens alkalmazás átirányítja a felhasználó böngészőjét az Authorizációs Szerver /authorize végpontjára. A kérés tartalmazza a client_id-t, a response_type=token paramétert, a kért scope-okat, a redirect_uri-t és egy state paramétert.

   GET /authorize?response_type=token&client_id=YOUR_CLIENT_ID&scope=email%20profile&redirect_uri=YOUR_REDIRECT_URI&state=RANDOM_STATE HTTP/1.1
   Host: auth.example.com

2. Felhasználó hitelesítése és hozzájárulása: Az Authorizációs Szerver hitelesíti a felhasználót és megjeleníti a hozzájárulási képernyőt.
3. Hozzáférési token visszaküldése (közvetlenül): Ha a felhasználó jóváhagyja, az Authorizációs Szerver közvetlenül visszaküldi a hozzáférési tokent a felhasználó böngészőjének a redirect_uri-ra, az URL hash fragmentumában (# után).

   HTTP/1.1 302 Found
   Location: YOUR_REDIRECT_URI#access_token=YOUR_ACCESS_TOKEN&token_type=Bearer&expires_in=3600&scope=email%20profile&state=RANDOM_STATE

   A kliens JavaScript kódja a böngészőben olvassa ki a tokent az URL-ből.

4. Erőforrás elérése: A kliens JavaScript kódja a megszerzett access token-nel küld kéréseket az Erőforrás Szervernek.

Biztonsági kockázatok:

Az Implicit Grant számos biztonsági kockázatot rejt magában, ezért elavulttá vált:

• Token az URL-ben: A hozzáférési token az URL-ben (hash fragmentum) utazik, ami azt jelenti, hogy:
  • Exponált lehet a böngésző előzményeiben.
  • Exponált lehet a szerver logokban, ha a szerver rögzíti a teljes URL-t.
  • Exponált lehet a referrer fejlécben, ha a felhasználó egy másik oldalra navigál.
• Nincs Client Secret: Mivel nincs szerver-oldali komponens, a kliens nem tudja biztonságosan tárolni a Client Secret-et, így a kliens autentikációja gyengébb.
• Nincs refresh token: Általában nem bocsátottak ki refresh tokent az Implicit Grant esetén, ami azt jelentette, hogy a hozzáférési token lejárta után a felhasználónak újra végig kellett mennie a teljes engedélyezési folyamaton.
• Code Injection támadások: Kockázatot jelent az engedélyezési kód injektálása, amelyet a PKCE hivatott kiküszöbölni.

Ezen okok miatt az Implicit Grant használata nem javasolt új fejlesztésekhez. Az Authorization Code Grant PKCE-vel a preferált választás kliens-oldali alkalmazásokhoz is.

3. Resource Owner Password Credentials Grant (Erőforrás Tulajdonos Jelszó Hitelesítő Adatai Típus)

A Resource Owner Password Credentials Grant lehetővé teszi a kliens alkalmazás számára, hogy közvetlenül a felhasználó felhasználónevét és jelszavát gyűjtse be, majd ezeket az Authorizációs Szervernek küldje a hozzáférési token megszerzéséhez. Ez a típus a legkevésbé biztonságos OAuth 2.0 flow, mivel a felhasználó közvetlenül a kliens alkalmazásnak adja meg a jelszavát.

Mikor használjuk?

• Csak rendkívül megbízható kliensek (pl. saját fejlesztésű, elsődleges alkalmazások, amelyek szorosan integrálódnak a szolgáltatással, vagy régebbi rendszerek migrációja során).
• Nem javasolt külső, harmadik féltől származó alkalmazásokhoz.

Részletes lépések:

1. Felhasználónév és jelszó bekérése: A kliens alkalmazás közvetlenül bekéri a felhasználótól a felhasználónevét és jelszavát (általában egy bejelentkezési űrlapon).
2. Token kérése: A kliens alkalmazás egy közvetlen POST kérést küld az Authorizációs Szerver /token végpontjára, amely tartalmazza a grant_type=password paramétert, a felhasználó felhasználónevét és jelszavát, valamint a client_id-t és client_secret-et (ha van).

   POST /token HTTP/1.1
   Host: auth.example.com
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=password&
   username=USER_NAME&
   password=USER_PASSWORD&
   client_id=YOUR_CLIENT_ID&
   client_secret=YOUR_CLIENT_SECRET&
   scope=email%20profile

3. Tokenek kibocsátása: Az Authorizációs Szerver hitelesíti a felhasználót a kapott felhasználónév és jelszó alapján. Ha a hitelesítés sikeres, egy JSON választ küld vissza, amely tartalmazza az access token-t és opcionálisan a refresh token-t.

Miért kerülendő a legtöbb esetben?

• Jelszó expozíció: A felhasználó jelszavát közvetlenül a kliens alkalmazásnak adja meg, ami ellentmond az OAuth alapvető céljának, a jelszó megosztásának elkerülésének. Ha a kliens alkalmazás kompromittálódik, a felhasználó jelszava is veszélybe kerülhet.
• Nincs felhasználói jóváhagyás: Nincs külön hozzájárulási képernyő, ahol a felhasználó finomhangoltan engedélyezhetné a hatóköröket. Az alkalmazás automatikusan megkapja a kért jogosultságokat, ha a jelszó helyes.
• Auditálhatóság hiánya: Nehezebb nyomon követni, hogy milyen alkalmazások férnek hozzá a felhasználó adataihoz, és milyen jogosultságokkal.

Ezt a grant típust csak akkor szabad használni, ha a szolgáltató és a kliens alkalmazás között rendkívül magas a bizalmi szint (pl. mindkettő ugyanattól a cégtől származik és szorosan integrált). Általában jobb, ha elkerüljük a használatát, és helyette az Authorization Code Grant-et preferáljuk.

4. Client Credentials Grant (Kliens Hitelesítő Adatai Típus)

A Client Credentials Grant egy teljesen más forgatókönyvre fókuszál: gép-gép kommunikációra, ahol nincs felhasználói interakció. Itt a kliens alkalmazás a saját nevében kér hozzáférést az erőforrásokhoz, nem egy felhasználó nevében.

Mikor használjuk?

• Szerver-szerver kommunikáció: Amikor egy szolgáltatásnak (kliens) hozzáférést kell szereznie egy másik szolgáltatás (erőforrás szerver) API-jához, és nincs közvetlen felhasználói kontextus. Például egy háttérfolyamat, amely statisztikákat gyűjt egy másik API-ból.
• Mikroszolgáltatások közötti kommunikáció.

Részletes lépések:

1. Token kérése: A kliens alkalmazás (amely ebben az esetben maga a szerver-oldali szolgáltatás) közvetlen POST kérést küld az Authorizációs Szerver /token végpontjára. A kérés tartalmazza a grant_type=client_credentials paramétert, valamint a client_id-t és a client_secret-et.

   POST /token HTTP/1.1
   Host: auth.example.com
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=client_credentials&
   client_id=YOUR_CLIENT_ID&
   client_secret=YOUR_CLIENT_SECRET&
   scope=api_read_write

2. Tokenek kibocsátása: Az Authorizációs Szerver hitelesíti a kliens alkalmazást a client_id és client_secret alapján. Ha a hitelesítés sikeres, egy JSON választ küld vissza, amely tartalmazza az access token-t. Ebben az esetben általában nincs refresh token, mivel nincs felhasználói kontextus, és a kliens bármikor kérhet új tokent a saját hitelesítő adataival.

   HTTP/1.1 200 OK
   Content-Type: application/json
   
   {
       "access_token": "YOUR_ACCESS_TOKEN_FOR_SERVICE_TO_SERVICE",
       "token_type": "Bearer",
       "expires_in": 3600,
       "scope": "api_read_write"
   }

3. Erőforrás elérése: A kliens alkalmazás a megszerzett access token-nel küld kéréseket az Erőforrás Szervernek, mint bármely más esetben.

Ez a típus egyszerű és hatékony gépek közötti kommunikációra, mivel nincs szükség felhasználói interakcióra, és a jogosultságok a kliens alkalmazáshoz, nem pedig egy adott felhasználóhoz kapcsolódnak.

Tokenek: Hozzáférési és Frissítő Tokenek

Az OAuth protokoll alapvető elemei a tokenek, amelyek a jogosultságok hordozói. Két fő típust különböztetünk meg: a hozzáférési tokent és a frissítő tokent. Ezek eltérő céllal és biztonsági megfontolásokkal rendelkeznek.

Access Token (Hozzáférési Token)

A hozzáférési token az a kulcs, amellyel a kliens alkalmazás hozzáfér a felhasználó védett erőforrásaihoz az Erőforrás Szerveren. Ez a token lényegében egy digitális „belépőjegy”, amely igazolja, hogy a kliensnek joga van a felhasználó nevében bizonyos műveleteket elvégezni egy meghatározott időn belül.

Formátum:

Az access token formátuma nem specifikált az OAuth 2.0 szabványban. Lehet:

• Opaque token: Egy véletlenszerűen generált, olvashatatlan karakterlánc. Az Erőforrás Szervernek egy belső mechanizmus (pl. adatbázis lekérdezés vagy Authorizációs Szerverrel való kommunikáció) segítségével kell ellenőriznie a token érvényességét és a hozzá tartozó jogosultságokat. Ez a leggyakoribb, mivel a token maga nem tartalmaz érzékeny információt, és ha kompromittálódik, nem árul el semmit a felhasználóról vagy a jogosultságokról.
• JWT (JSON Web Token): Egy öntartalmazó token, amely a tokenbe kódolva tartalmazza a jogosultságokat, a lejárati időt és más metaadatokat. A JWT-ket digitálisan aláírják, így az Erőforrás Szerver önállóan, az Authorizációs Szerver megkérdezése nélkül is ellenőrizheti az aláírást és a token érvényességét. Ez gyorsabb ellenőrzést tesz lehetővé, de ha a token tartalmában érzékeny információ van, az dekódolható (bár nem módosítható az aláírás miatt).

Élettartam:

A hozzáférési tokenek általában rövid élettartamúak (pl. 5 perc, 1 óra, vagy néhány óra). Ez egy fontos biztonsági intézkedés. Ha egy access token kompromittálódik, a támadó csak korlátozott ideig használhatja azt, mielőtt lejárna. A rövid élettartam miatt a kliens alkalmazásoknak gyakran kell új tokent kérniük, amihez a refresh tokent használják.

Célja és felhasználása:

• Hozzáférést biztosít a védett erőforrásokhoz az Erőforrás Szerveren.
• Minden API kéréshez mellékelni kell az Authorization: Bearer [access_token] fejlécben.
• Az Erőforrás Szerver ellenőrzi a token érvényességét (aláírás, lejárat, hatókörök).

Biztonsági szempontok:

• Ne tároljuk kliens oldalon (böngészőben, localStorage-ban): Különösen érzékeny adatokat tartalmazó tokeneket ne tároljunk a böngészőben, mivel XSS (Cross-Site Scripting) támadásokkal ellophatók. Helyette használjunk HTTP-only sütiket, vagy tároljuk szerver-oldalon (ahol ez lehetséges).
• Mindig HTTPS-en keresztül továbbítsuk: Minden kommunikációnak, amely tokeneket tartalmaz, titkosítottnak kell lennie az adatok lehallgatásának megakadályozására.
• Korlátozott hatókör: A tokennek csak a minimálisan szükséges jogosultságokat kell tartalmaznia (least privilege principle).

Refresh Token (Frissítő Token)

A frissítő token egy hosszú élettartamú token, amelyet az Authorizációs Szerver bocsát ki a hozzáférési token mellett (ha a kliens ezt kéri és az Authorizációs Szerver támogatja). Célja, hogy a kliens alkalmazás új hozzáférési tokent szerezhessen anélkül, hogy a felhasználónak újra végig kellene mennie a teljes engedélyezési folyamaton.

Célja és működése:

• Felhasználói élmény javítása: Megakadályozza, hogy a felhasználónak minden alkalommal újra be kelljen jelentkeznie, amikor a hozzáférési token lejár.
• Biztonság: Mivel a hozzáférési tokenek rövid élettartamúak, a frissítő tokenek lehetővé teszik a folyamatos hozzáférést, miközben minimalizálják a kitettséget. Ha egy access token kompromittálódik, gyorsan lejár, és a frissítő tokent vissza lehet vonni.
• Token rotáció: A frissítő tokenek felhasználhatók a token rotációra, ahol minden új access token kéréshez egy új refresh token is kibocsátásra kerül, növelve a biztonságot.

Hosszú élettartam:

A refresh tokenek élettartama sokkal hosszabb lehet, mint az access tokeneké (pl. napok, hetek, hónapok, vagy akár visszavonásig). Ezért különösen fontos a biztonságos tárolásuk.

Biztonsági megfontolások:

• Szerver-oldali tárolás: A refresh tokeneket mindig biztonságosan, szerver-oldalon kell tárolni (pl. titkosított adatbázisban), soha nem kliens oldalon (böngészőben, mobiltelefonon). Ez azért van, mert a refresh token az access token megszerzésének kulcsa, és ha kompromittálódik, a támadó hosszú ideig hozzáférhet a felhasználó adataihoz.
• Egyszeri használat (One-Time Use): A legjobb gyakorlat szerint a refresh tokeneknek egyszer használatosnak kell lenniük. Minden sikeres refresh kérés után új refresh tokent kell kibocsátani, és a régit érvényteleníteni. Ez megnehezíti a replay támadásokat.
• Visszavonás (Revocation): Az Authorizációs Szervernek rendelkeznie kell egy mechanizmussal, amellyel a felhasználó vagy az adminisztrátor bármikor visszavonhatja a refresh tokeneket (pl. a „Kijelentkezés minden eszközről” funkcióval), ezzel azonnal érvénytelenítve az összes kapcsolódó hozzáférést.
• IP-címhez kötés: Bizonyos esetekben a refresh tokent az azt kérő IP-címhez köthetik, további biztonsági réteget adva.

A tokenek megfelelő kezelése, tárolása és élettartamuk beállítása kulcsfontosságú az OAuth alapú rendszerek biztonságához. A rövid élettartamú hozzáférési tokenek és a biztonságosan tárolt, visszavonható frissítő tokenek kombinációja biztosítja a rugalmas, mégis biztonságos hozzáférést.

Biztonsági megfontolások és gyakori hibák az OAuth implementációban

Bár az OAuth célja a biztonság növelése, a helytelen implementáció súlyos sebezhetőségeket eredményezhet. Fontos, hogy a fejlesztők és az üzemeltetők tisztában legyenek a protokoll biztonsági aspektusaival és a gyakori buktatókkal.

1. Redirect URI validáció

A Redirect URI (átirányítási URI) a legkritikusabb biztonsági paraméter az OAuth-ban. Az Authorizációs Szervernek szigorúan ellenőriznie kell, hogy az engedélyezési kérésben megadott redirect_uri pontosan megegyezik-e azzal az URI-val, amelyet a kliens alkalmazás a regisztráció során előzetesen regisztrált. Ha ez az ellenőrzés hiányzik vagy nem elég szigorú, egy támadó átirányíthatja az engedélyezési kódot vagy tokent egy rosszindulatú webhelyre (Open Redirector támadás).

• Helyes gyakorlat: Regisztráljunk teljes, pontos URI-kat, ne csak domaineket. Kerüljük a wildcard-ok (pl. *.example.com) használatát, hacsak nem feltétlenül szükséges és nem biztosítunk további ellenőrzési rétegeket.
• Gyakori hiba: Túl megengedő átirányítási URI-k, például csak a domain ellenőrzése, vagy nem HTTPS URI-k engedélyezése.

2. State paraméter használata

Az state paraméter egy véletlenszerűen generált, egyedi érték, amelyet a kliens alkalmazás hoz létre, amikor elindítja az engedélyezési kérést. Ezt a paramétert az Authorizációs Szervernek sértetlenül vissza kell küldenie a kliensnek az átirányítás során. A kliens alkalmazásnak ezután ellenőriznie kell, hogy a kapott state paraméter megegyezik-e azzal, amit eredetileg elküldött. Ez megakadályozza a CSRF (Cross-Site Request Forgery) támadásokat.

• Helyes gyakorlat: Minden engedélyezési kéréshez generáljunk egyedi, kriptográfiailag erős state paramétert, és tároljuk biztonságosan a kliens oldalon (pl. session-ben). Ellenőrizzük a visszakapott értéket.
• Gyakori hiba: A state paraméter kihagyása vagy nem megfelelő ellenőrzése.

3. PKCE (Proof Key for Code Exchange) fontossága

Mint korábban említettük, a PKCE kiterjesztés kulcsfontosságú az Authorization Code Grant biztonságossá tételéhez, különösen a „public client”-ek (mint a mobil- vagy SPA alkalmazások) esetében, ahol a Client Secret nem tárolható biztonságosan. A PKCE megakadályozza az authorization code injection támadásokat.

• Helyes gyakorlat: Mindig használjunk PKCE-t az Authorization Code Grant-tel, még szerver-oldali alkalmazások esetén is, ha az Authorizációs Szerver támogatja.
• Gyakori hiba: PKCE kihagyása, ami sebezhetővé teszi az alkalmazást a kód lopásával szemben.

4. Token tárolás (különösen kliens oldalon)

A tokenek biztonságos tárolása az egyik legnehezebb feladat. Különösen az access tokenek és refresh tokenek tárolása kliens-oldali (böngészőben futó) JavaScript alkalmazásokban jelent komoly kihívást.

• Access Token:
  • Kerüljük a localStorage-t és sessionStorage-t: Ezek az API-k sebezhetők XSS támadásokkal szemben. Egy rosszindulatú szkript könnyen ellophatja a tokeneket.
  • Alternatíva: Használjunk HTTP-only sütiket (cookie-kat) az access token tárolására (ha a token elég rövid és a kliens szerver-oldalon tudja kezelni a sütit), vagy tároljuk a tokent a böngésző memóriájában (ami újraindításkor elveszik). A legbiztonságosabb, ha a token sosem kerül a böngészőbe, hanem szerver-oldalon marad (ezért jobb az Authorization Code flow).
• Refresh Token:
  • Soha ne tároljuk kliens oldalon (böngészőben): A refresh tokenek hosszú élettartamúak, és ha kompromittálódnak, hosszú távú hozzáférést biztosíthatnak.
  • Mindig szerver-oldalon, titkosítva tároljuk: Adatbázisban, titkosítva, és csak biztonságos szerver-szerver kommunikációval használjuk.

5. Scope-ok helyes kezelése

A scope-ok (hatókörök) határozzák meg a kliens alkalmazás jogosultságait. A „least privilege” elvet kell követni: az alkalmazásnak csak a minimálisan szükséges jogosultságokat kell kérnie.

• Helyes gyakorlat: Kérjünk csak azokat a scope-okat, amelyekre az alkalmazásnak feltétlenül szüksége van a működéséhez. A felhasználónak is meg kell értenie, mihez ad hozzáférést.
• Gyakori hiba: Túl széles scope-ok kérése (pl. profile:* vagy all), ami feleslegesen nagy hozzáférést ad az alkalmazásnak.

6. HTTPS/TLS használata

Az OAuth 2.0 alapvetően feltételezi, hogy minden kommunikáció titkosított csatornán (HTTPS/TLS) keresztül történik. Ez megakadályozza az adatok (beleértve a tokeneket és kódokat) lehallgatását (man-in-the-middle támadások).

• Helyes gyakorlat: Minden kommunikációnak HTTPS-en keresztül kell történnie, mind az Authorizációs Szerver, mind az Erőforrás Szerver, mind a kliens alkalmazás és a felhasználó böngészője között.
• Gyakori hiba: HTTP használata bizonyos végpontokon, ami sebezhetővé teszi az adatokat.

7. Kliens titok (Client Secret) kezelése

A Client Secret egy bizalmas kulcs, amelyet az Authorizációs Szerver a kliens alkalmazás hitelesítésére használ. Csak a konfidenciális kliensek (azaz olyan kliensek, amelyek képesek biztonságosan tárolni egy titkot, pl. szerver-oldali webalkalmazások) használhatják.

• Helyes gyakorlat: A Client Secret-et soha ne tegyük közzé nyilvánosan (pl. kliens-oldali kódban, GitHub repóban). Tároljuk biztonságosan (környezeti változók, titkosítási szolgáltatások), és csak szerver-szerver kommunikációban használjuk.
• Gyakori hiba: Client Secret beégetése a kliens-oldali kódba, ami azonnali kompromittálódáshoz vezet.

8. Token visszavonás (Revocation)

Képességnek kell lennie a kibocsátott tokenek (különösen a refresh tokenek) visszavonására, ha azok kompromittálódnak, vagy a felhasználó visszavonja az engedélyt.

• Helyes gyakorlat: Implementáljunk token visszavonási végpontot az Authorizációs Szerveren. A kliens alkalmazásoknak képesnek kell lenniük a tokenek visszavonására, és a felhasználóknak is lehetőséget kell biztosítani (pl. „Kijelentkezés minden eszközről” funkció).

Az OAuth implementáció során a biztonság mindig a legfontosabb szempont. A protokoll helyes megértése és a legjobb gyakorlatok követése elengedhetetlen a robusztus és biztonságos rendszerek kiépítéséhez.

OAuth 1.0 vs. OAuth 2.0 – Egy rövid összehasonlítás

Bár a cikk az OAuth 2.0-ra fókuszál, érdemes röviden megemlíteni az elődjét, az OAuth 1.0-t, és a fő különbségeket, amelyek a 2.0-s verzió létrejöttéhez vezettek.

Az OAuth 1.0 volt az első széles körben elfogadott szabvány a delegált authorizációra. Fő jellemzője, hogy a kérések integritását kriptográfiai aláírásokkal biztosította. Ez azt jelentette, hogy minden API kéréshez egy komplex aláírási mechanizmust kellett alkalmazni, amely magában foglalta a kérés paramétereit, az URI-t és a Client Secret-et. Ez a megközelítés rendkívül biztonságos volt a lehallgatás és a manipuláció ellen, még nem titkosított csatornán (HTTP) keresztül is.

Azonban az OAuth 1.0 jelentős hátránya volt a komplexitása. Az aláírási folyamat implementálása bonyolult volt, különösen különböző programnyelveken és platformokon. Ez nehézkessé tette a fejlesztést és a hibakeresést, és akadályozta a széles körű elterjedést, különösen a mobil- és kliens-oldali alkalmazások esetében.

Az OAuth 2.0 válaszként született meg ezekre a kihívásokra. Fő célja az volt, hogy egyszerűbbé, rugalmasabbá és könnyebben implementálhatóvá tegye a delegált authorizációt. A legfontosabb változások a következők voltak:

• HTTPS/TLS használata: Az OAuth 2.0 teljes mértékben a HTTPS protokollra támaszkodik a kommunikáció titkosításához és integritásának biztosításához. Ez megszüntette a szükségét a komplex kriptográfiai aláírásoknak minden egyes kérésnél, ami jelentősen egyszerűsítette a protokollt. A biztonságot a szállítási réteg (TLS) garantálja.
• Rugalmasabb Grant Típusok: Az 2.0 verzió bevezette a különböző „grant type”-okat, amelyek lehetővé teszik a fejlesztők számára, hogy a legmegfelelőbb flow-t válasszák a különböző alkalmazás-típusokhoz (web, mobil, asztali, gép-gép). Ez a rugalmasság növelte a protokoll alkalmazhatóságát.
• Elválasztott szerepkörök: Tisztábban definiálta a szereplőket (Authorizációs Szerver, Erőforrás Szerver), ami segítette a rendszerek modulárisabb tervezését.
• Token formátum rugalmassága: Az 2.0 nem írja elő a token formátumát, így a szolgáltatók szabadon választhatnak az opaque tokenek és a JWT-k között, vagy más formátumokat is használhatnak.

Összefoglalva, az OAuth 1.0 a „biztonság a komplexitás árán” megközelítést követte, míg az OAuth 2.0 a „biztonság a HTTPS-re támaszkodva, egyszerűbb implementációval” filozófiát vallja. A 2.0-s verzió szélesebb körű elfogadottsága és elterjedése bizonyítja, hogy a rugalmasság és az egyszerűbb implementáció kulcsfontosságú volt a delegált authorizáció standardjának kialakításában.

OAuth és OpenID Connect (OIDC) – Az identitásréteg az authorizáció tetején

Gyakran merül fel a kérdés, hogy mi a különbség az OAuth és az OpenID Connect (OIDC) között, és hogyan viszonyulnak egymáshoz. Bár szorosan kapcsolódnak, alapvető különbségek vannak a céljaikban.

Mi az OpenID Connect (OIDC)?

Az OpenID Connect (OIDC) egy identitásréteg, amely az OAuth 2.0 protokoll tetejére épül. Míg az OAuth 2.0 kizárólag a jogosultságkezelésre (authorizációra) fókuszál (azaz „mit tehet egy alkalmazás a felhasználó nevében?”), addig az OIDC célja a felhasználó hitelesítése (autentikációja) és a felhasználói identitás információinak biztonságos átadása a kliens alkalmazásnak.

Egyszerűen fogalmazva:

• OAuth 2.0: „Engedélyt adok X alkalmazásnak, hogy hozzáférjen a Y adatomhoz Z szolgáltatásban.”
• OpenID Connect: „Én vagyok Pista, és az X alkalmazás meg tudja erősíteni, hogy valóban én vagyok Pista, és hozzáférhet a nevemhez, e-mail címemhez és profilképemhez.”

Fő cél: Autentikáció és Identitás Információ

Az OIDC kiterjeszti az OAuth 2.0-t azzal, hogy bevezet egy új tokent, az ID Token-t, és néhány szabványos végpontot a felhasználói információk lekérdezésére.

ID Token szerepe:

Az ID Token egy JSON Web Token (JWT), amelyet az Authorizációs Szerver bocsát ki az access token mellett. Ez az ID Token tartalmazza a hitelesített felhasználóval kapcsolatos alapvető profilinformációkat (ún. „claims”), mint például:

• iss (issuer): A token kibocsátója (Authorizációs Szerver URL-je).
• sub (subject): A felhasználó egyedi azonosítója a kibocsátó rendszerében.
• aud (audience): Az a kliens alkalmazás, amelynek a token szól.
• exp (expiration time): A token lejárati ideje.
• iat (issued at time): A token kibocsátásának ideje.
• auth_time: Az időpont, amikor a felhasználó hitelesítve lett.
• Opcionális „claims” (pl. name, email, given_name, family_name, picture), ha a kliens kéri és a felhasználó engedélyezi.

Az ID Token digitálisan alá van írva, így a kliens alkalmazás ellenőrizni tudja annak integritását és eredetiségét. Mivel JWT formátumú, a kliens azonnal dekódolhatja és felhasználhatja a benne lévő információkat, anélkül, hogy további API hívásokat kellene kezdeményeznie.

Mikor használjuk az OIDC-t?

• Egyszeri bejelentkezés (Single Sign-On – SSO): Az OIDC a de facto szabvány az SSO megoldásokhoz, ahol a felhasználó egyszer jelentkezik be egy szolgáltatónál (pl. Google, Facebook), és ezáltal több, különböző alkalmazásba is be tud lépni anélkül, hogy újra meg kellene adnia a hitelesítő adatait.
• Felhasználói profil adatok lekérése: Ha egy alkalmazásnak szüksége van a felhasználó alapvető profiladataira (név, e-mail, kép), az OIDC biztonságos és szabványos módon biztosítja ezt az ID Token és az opcionális /userinfo végpont segítségével.
• Felhasználói munkamenet kezelése: Az OIDC definiál mechanizmusokat a felhasználói munkamenetek kezelésére, mint például a kijelentkezés (logout) és a munkamenet ellenőrzése.

Az OIDC folyamata (az OAuth 2.0-ra épülve):

Az OIDC flow lényegében az Authorization Code Grant (vagy ritkábban az Implicit Grant) kiterjesztése. A kérés során a scope paraméterbe bekerül az openid érték, és gyakran a profile és email is. A válaszban az Authorizációs Szerver az access token és refresh token mellett kibocsát egy ID Token-t is. A kliens alkalmazás ezután ellenőrzi az ID Token-t, és felhasználja a benne lévő identitás információkat.

Összefoglalva, az OAuth 2.0 a jogosultságok delegálásának keretrendszere, míg az OpenID Connect egy identitásréteg, amely az OAuth 2.0 tetejére épül, hogy szabványosított módon kezelje a felhasználói hitelesítést és a profiladatok átadását. A legtöbb „Bejelentkezés Google-lel” vagy „Bejelentkezés Facebookkal” típusú funkció valójában az OpenID Connect-et használja, amely az OAuth 2.0-t alkalmazza a háttérben.

Gyakorlati alkalmazások és példák az OAuth használatára

Az OAuth protokoll ma már szinte mindenhol jelen van az online világban, ahol különböző szolgáltatásoknak vagy alkalmazásoknak kell egymással kommunikálniuk a felhasználó nevében. Nézzünk néhány konkrét példát, amelyek szemléltetik a protokoll sokoldalúságát és elterjedtségét.

1. Bejelentkezés közösségi média vagy nagy tech cégek fiókjával (SSO és OIDC)

Ez valószínűleg a leggyakoribb példa, amellyel a felhasználók találkoznak. Amikor egy weboldalon vagy mobilalkalmazásban megjelenik a „Bejelentkezés Google-lel”, „Bejelentkezés Facebookkal”, „Bejelentkezés Apple ID-val” vagy „Bejelentkezés GitHubbal” gomb, az OpenID Connect-et (amely az OAuth 2.0-ra épül) használják. A folyamat a következő:

• A felhasználó rákattint a gombra a kliens alkalmazásban.
• A kliens átirányítja a felhasználót a Google/Facebook/Apple hitelesítési oldalára (Authorizációs Szerver).
• A felhasználó bejelentkezik a Google/Facebook/Apple fiókjába (ha még nem tette meg).
• A Google/Facebook/Apple megkérdezi a felhasználót, hogy engedélyezi-e az adott alkalmazásnak a hozzáférést bizonyos adatokhoz (pl. név, e-mail cím, profilkép – ezek a scope-ok).
• Ha a felhasználó engedélyezi, a Google/Facebook/Apple visszaküldi az engedélyezési kódot és az ID tokent a kliens alkalmazásnak.
• A kliens alkalmazás a kóddal lekéri a hozzáférési tokent, majd az ID tokent felhasználva azonosítja a felhasználót, és bejelentkezteti őt a saját rendszerébe.

Ez a megoldás rendkívül kényelmes a felhasználók számára, mivel nem kell újabb felhasználónevet és jelszót megjegyezniük, és biztonságosabb is, mert a jelszavukat sosem adják meg a harmadik fél alkalmazásnak.

2. API hozzáférés delegálása (pl. Slack, Trello, Dropbox)

Számos online szolgáltatás kínál API-kat, amelyek lehetővé teszik más alkalmazások számára, hogy interakcióba lépjenek az adott szolgáltatás adataival. Az OAuth segítségével a felhasználók biztonságosan engedélyezhetik ezeket az integrációkat.

• Példa: Egy projektmenedzsment eszköz (kliens) szeretne fájlokat feltölteni a felhasználó Dropbox (erőforrás szerver) fiókjába.
• A projektmenedzsment eszköz kéri a felhasználótól a Dropbox hozzáférés engedélyezését.
• A felhasználó átirányítódik a Dropbox Authorizációs Szerverére.
• A Dropbox megkérdezi a felhasználót, hogy engedélyezi-e a projektmenedzsment eszköznek a fájlok olvasását/írását (scope: files.content.write, files.content.read).
• Ha a felhasználó engedélyezi, a projektmenedzsment eszköz hozzáférési tokent kap a Dropbox API-hoz, amellyel feltöltheti vagy letöltheti a fájlokat a felhasználó nevében. A Dropbox sosem kapja meg a felhasználó Dropbox jelszavát.

Hasonlóan működnek a Slack integrációk, ahol egy külső alkalmazás üzeneteket küldhet egy csatornára, vagy a Trello integrációk, ahol egy külső eszköz kezelheti a felhasználó tábláit.

3. Mobil alkalmazások

A mobilalkalmazások gyakran használnak OAuth-ot a felhasználók bejelentkeztetésére és a külső szolgáltatásokhoz való hozzáférésre. Mivel a mobilalkalmazások „public client”-eknek számítanak (nem tudják biztonságosan tárolni a Client Secret-et), a PKCE kiterjesztésű Authorization Code Grant a preferált módszer.

• Egy mobil fotószerkesztő alkalmazás szeretne hozzáférni a felhasználó Google Photos könyvtárához.
• A felhasználó a mobilalkalmazásból elindítja a Google Photos integrációt.
• A mobilalkalmazás beépített böngészőjében vagy a rendszer alapértelmezett böngészőjében megjelenik a Google bejelentkezési és hozzájárulási képernyője.
• A folyamat a PKCE-s Authorization Code Grant szerint zajlik, és a mobilalkalmazás access tokent kap a Google Photos API-hoz.

4. Mikroszolgáltatások közötti kommunikáció

Nagyobb rendszerekben, amelyek mikroszolgáltatási architektúrára épülnek, az OAuth Client Credentials Grant típusa gyakran használatos a szolgáltatások közötti biztonságos kommunikációra.

• Egy „Rendeléskezelő” mikroszolgáltatásnak szüksége van a „Készlet” mikroszolgáltatás API-jának elérésére, hogy ellenőrizze a termékek elérhetőségét.
• A Rendeléskezelő szolgáltatás (kliens) a saját Client ID-jével és Client Secret-jével kér hozzáférési tokent egy Authorizációs Szervertől.
• A kapott tokennel a Rendeléskezelő szolgáltatás kéréseket küld a Készlet szolgáltatás API-jának.
• Ebben az esetben nincs felhasználói interakció, a jogosultságok a szolgáltatások közötti bizalmon alapulnak.

5. IoT (Internet of Things) eszközök

Az IoT eszközök is használhatják az OAuth-ot a biztonságos autentikációra és authorizációra. Bár a folyamat kissé eltérhet az eszközök korlátozott beviteli lehetőségei miatt (pl. Device Flow), az alapelv ugyanaz: egy eszköz hozzáférést kér a felhasználó nevében, anélkül, hogy a felhasználó megosztaná a jelszavát az eszközzel.

Ezek a példák jól mutatják, hogy az OAuth nem csak egy elméleti protokoll, hanem egy rendkívül praktikus és széles körben alkalmazott megoldás a modern, összekapcsolt digitális ökoszisztémában. A biztonságos és delegált hozzáférés alapvető fontosságú a felhasználói adatok védelmében és a szolgáltatások közötti zökkenőmentes integrációban.

Az OAuth jövője és kihívásai

Az OAuth protokoll folyamatosan fejlődik, hogy megfeleljen a változó biztonsági kihívásoknak és a digitális környezet igényeinek. Néhány fontos irány és kihívás a jövőre nézve:

1. OAuth 2.1

Az OAuth 2.1 egy kezdeményezés, amely a jelenlegi OAuth 2.0 specifikációt kívánja egyszerűsíteni és biztonságosabbá tenni, a legjobb gyakorlatok és a tanulságok alapján. Főbb változások:

• Az Implicit Grant elavulttá tétele: Helyette az Authorization Code Grant PKCE kiterjesztéssel való használatát javasolja minden kliens típushoz.
• PKCE kötelezővé tétele: A PKCE használata kötelezővé válik az Authorization Code Grant-hez a public client-ek (mobil, SPA) számára.
• Client Secret kötelezővé tétele: A confidential client-ek (szerver-oldali) számára a Client Secret kötelezővé válik a token exchange során.
• Refresh tokenek egyszeri használata: Erősebb ajánlás a refresh tokenek egyszeri használatára (rotating refresh tokens).
• Szigorúbb Redirect URI validáció.

Az OAuth 2.1 célja, hogy egyértelműbbé tegye a legjobb gyakorlatokat és csökkentse a hibás implementációk számát, amelyek sebezhetőségekhez vezethetnek.

2. FAPI (Financial-grade API)

A FAPI (Financial-grade API) egy olyan profilja az OAuth 2.0-nak és az OpenID Connect-nek, amelyet kifejezetten a pénzügyi szektor szigorú biztonsági követelményeinek megfelelően alakítottak ki. Ez a profil további biztonsági intézkedéseket vezet be, mint például:

• Minden kommunikáció HTTPS/TLS 1.2+ protokollon keresztül történik, szigorú titkosítási algoritmusokkal.
• Minden token és kód digitális aláírása (JWT alapú).
• Fejlett kliens hitelesítési módszerek (pl. mTLS – mutual TLS).
• Szigorúbb token élettartam és visszavonási szabályok.

A FAPI mutatja, hogy az OAuth keretrendszer elég rugalmas ahhoz, hogy a legmagasabb biztonsági igényeket is kielégítse, és valószínűleg más iparágak is átveszik majd a jövőben.

3. WebAuthn integráció

A WebAuthn (Web Authentication) egy webes szabvány, amely lehetővé teszi a jelszó nélküli hitelesítést kriptográfiai kulcsok és hardveres biztonsági eszközök (pl. ujjlenyomat-olvasók, YubiKey) segítségével. Az OAuth és az OIDC integrációja a WebAuthn-nel lehetővé teszi a felhasználók számára, hogy jelszó nélkül jelentkezzenek be az Authorizációs Szerverre, ami tovább növeli a biztonságot és a felhasználói élményt.

4. Felhasználói élmény és biztonság egyensúlya

Az OAuth folyamatos kihívása az, hogy megtalálja az egyensúlyt a biztonság és a felhasználói élmény között. A túl bonyolult vagy túl sok lépést tartalmazó folyamatok elriaszthatják a felhasználókat, míg a túl egyszerűsített megoldások biztonsági kockázatokat rejtenek. A jövőbeli fejlesztéseknek figyelembe kell venniük mindkét szempontot.

5. Fejlettebb fenyegetések és védelem

Ahogy a technológia fejlődik, úgy fejlődnek a támadási módszerek is. Az OAuth implementációknak folyamatosan alkalmazkodniuk kell az új fenyegetésekhez (pl. token replay támadások, fejlettebb adathalászat). Ez magában foglalja a folyamatos frissítéseket, a biztonsági auditokat és a legjobb gyakorlatok szigorú betartását.

6. Decentralizált identitás és blokklánc technológiák

Bár még a kezdeti fázisban van, a decentralizált identitás (DID) és a blokklánc technológiák potenciálisan befolyásolhatják az autentikáció és authorizáció jövőjét. Azonban az OAuth és OIDC bevált és széles körben elterjedt szabványok maradnak a közeli jövőben, és valószínűleg integrálódnak az új technológiákkal, ahelyett, hogy teljesen felváltanák azokat.

Az OAuth egy dinamikusan fejlődő terület, amely kulcsszerepet játszik a modern digitális világ biztonságában és interoperabilitásában. A folyamatos fejlesztések és a közösségi erőfeszítések biztosítják, hogy továbbra is hatékony és biztonságos megoldást nyújtson a delegált jogosultságkezelésre.