Amikor bejelentkezik egy modern egyoldalas alkalmazásba (mint például a React vagy a Vue) vagy egy mobilalkalmazásba, a szervernek módot kell adni arra, hogy emlékezzen, ki vagy. Hagyományosan ezt úgy tette, hogy egy "munkamenet-azonosítót" tárolt egy hatalmas adatbázisban a szerveren, és egy cookie-t helyezett el a böngészőjében. Minden alkalommal, amikor egy gombra kattintott, a szervernek meg kellett keresnie az azonosítót az adatbázisában. Ezt állapotalapú hitelesítésnek nevezik.
A mikroszolgáltatások és a felhőskálázás korszakában azonban az adatbázisok szűk keresztmetszetekké váltak. Ennek megoldására a fejlesztők állam nélküli hitelesítést alkalmaztak a JSON Web Tokens (JWT) segítségével. A JWT-vel a kiszolgálónak nem kell emlékeznie arra, hogy ki vagy – a böngészője pontosan megmondja a szervernek, hogy kicsoda, és ezt titkosítással bizonyítja.
A JWT anatómiája
Ha egy modern alkalmazásba való bejelentkezés után ellenőrzi a hálózati forgalmat, valószínűleg megjelenik az „Authorization: Bearer” fejléc, amelyet egy hosszú, véletlenszerű karaktersorozat követ két ponttal elválasztva. Ez egy JWT.
A JWT pontosan három részből áll: Header.Payload.Signature.
1. A fejléc
Az első rész egy Base64URL kódolású JSON-objektum, amely egyszerűen leírja a tokent. Általában két tulajdonságot tartalmaz: a token típusát (JWT) és a használt aláírási algoritmust (például HMAC SHA256 vagy RSA).
2. A rakomány (követelések)
A középső rész szintén egy Base64URL kódolású JSON-objektum. Itt élnek a tényleges adatok. Ezeket az adatokat "követeléseknek" nevezik. Tartalmazhatja például az Ön felhasználói azonosítóját, szerepkörét (pl. „Adminisztrátor”) és egy lejárati időbélyeget. Mivel ez a rakomány minden kéréshez csatolva van, a szerver azonnal tudja, hogy ki vagy anélkül, hogy lekérdezne egy adatbázist.
KRITIKUS FIGYELMEZTETÉS: A hasznos teher csak kódolt, nem titkosítva. Bárki, aki elkap egy JWT-t, könnyen dekódolhatja és elolvashatja a hasznos terhet. Soha ne tároljon jelszavakat, társadalombiztosítási számokat vagy bizalmas adatokat a JWT rakományban.
3. Az aláírás
Ha bárki el tudja olvasni és szerkeszteni a hasznos adatokat, mi akadályozza meg a rosszindulatú felhasználót abban, hogy „Felhasználó”-ról „Adminisztrátor”-ra változtassa a szerepkörét? A válasz az aláírás.
Az aláírás létrehozásához a szerver veszi a fejlécet, a hasznos terhet és egy rendkívül biztonságos titkos kulcsot (csak a szerver ismeri), és egy kriptográfiai algoritmuson (például SHA256-on) keresztül futtatja őket. Az eredményül kapott hash lesz az aláírás.
Amikor a kiszolgáló visszakap egy tokent az ügyféltől, a titkos kulcs segítségével újraszámítja az aláírást. Ha a felhasználó manipulálta a hasznos adatot (akár egyetlen betűt is megváltoztatott), az újraszámított aláírás nem egyezik meg a token aláírásával, és a szerver azonnal visszautasítja a kérést, mint hamisat.
Vizsgálja meg biztonságosan a tokeneket
El kell olvasnia a JWT hasznos terhét az alkalmazás hibakereséséhez? Offline JWT dekóderünk segítségével azonnal megvizsgálhatja a követeléseket anélkül, hogy elküldené érzékeny tokent egy távoli szerverre.
Nyissa meg a JWT dekódertMiért szeretik a mikroszolgáltatások a JWT-ket?
Képzelj el egy olyan céget, mint a Netflix. Van egy hitelesítési kiszolgálójuk, egy videofolyam-kiszolgálójuk és egy számlázószerverük. Ha hagyományos munkameneteket használnának, minden egyes szervernek folyamatosan kommunikálnia kellene egy központi adatbázissal, hogy ellenőrizze, be van-e jelentkezve a felhasználó.
JWT-k esetén a hitelesítési kiszolgáló egy privát kulccsal írja alá a tokent. A felhasználó ezután közvetlenül továbbítja a tokent a videoszervernek. Mivel a Videoszerver rendelkezik nyilvános kulccsal, függetlenül tudja ellenőrizni az aláírást. A Videoszerver pontosan tudja, ki a felhasználó anélkül, hogy beszélne a hitelesítési szerverrel vagy egy adatbázissal. Ez lehetővé teszi, hogy az infrastruktúra szűk keresztmetszetek nélkül végtelenül méretezhető legyen.
A sötét oldal: Token érvénytelenítése
A JWT-k nem tökéletesek. Legnagyobb erősségük (hontalanságuk) egyben a legnagyobb gyengeségük is. Mivel a szerver nem tartja nyilván az aktív tokeneket, nem lehet egyszerűen kijelentkezni egy felhasználót, vagy érvényteleníteni egy adott tokent, mielőtt lejárna.
Ha egy hacker ellopja a felhasználó JWT-jét, a hacker teljes hozzáféréssel rendelkezik, amíg a token lejárati időbélyege le nem telik. Ennek a kockázatnak a csökkentése érdekében a biztonsági mérnökök két jelű rendszert használnak:
- Hozzáférési tokenek: API-kérésekhez használt rövid élettartamú JWT-k (pl. 15 perc).
- Frissítési tokenek: hosszú élettartamú, állapotjelző, biztonságosan tárolt tokenek, amelyeket szigorúan új hozzáférési tokenek kérésére használnak. Ha egy fiókot feltörnek, a szerver visszavonja a frissítési tokent, és a hacker hozzáférési tokenje 15 percen belül természetesen elpusztul.
Gyakran Ismételt Kérdések (GYIK)
Hol tároljam a JWT-t a frontenden?
A JWT-k localStorage-ban való tárolása sebezhetővé teszi őket a Cross-Site Scripting (XSS) támadásokkal szemben. A JWT webböngészőben való tárolásának legbiztonságosabb helye egy HttpOnly cookie-ban van, amely megakadályozza, hogy a JavaScript hozzáférjen.
Mi történik, ha a szerverem titkos kulcsa kiszivárog?
Katasztrófa. Ha egy hacker megszerzi az Ön HMAC titkos kulcsát vagy RSA privát kulcsát, érvényes JWT-ket generálhat bármilyen hasznos terheléssel. Létrehozhatnak olyan tokeneket, amelyek "Super Admin" jogosultságokat adnak maguknak, és a szerver elfogadja őket érvényesnek. Azonnal el kell forgatnia a kulcsokat.
Gyorsabbak a JWT-k, mint a munkamenet-cookie-k?
Nem feltétlenül. A JWT-k fájlmérete lényegesen nagyobb, mint egy 32 karakteres munkamenet-azonosító, ami azt jelenti, hogy minden kérésre több hálózati sávszélességet fogyasztanak. Sebességbeli előnyük teljes mértékben abból fakad, hogy megkerülik az adatbázis-kereséseket a háttérben.