A JSON Web Tokent gyakran bejelentkezési tokenként mutatják be, de a formátum önmagában senkit sem autentikál. Egy kompakt üzenet állításokkal: ki bocsátotta ki, kit jelöl, mely szolgáltatás fogadhatja el, és meddig érvényes. A fogadó elolvashatja ezeket, majd kriptográfiai aláírással ellenőrizheti, hogy megbízható kibocsátó készítette-e, és változott-e útközben. A biztonságot nem az idegennek látszó string, hanem a kulcskezelés és a szigorú validáció adja.

A három szegmensnek külön feladata van

Egy aláírt JWT headerből, payloadból és signature-ből áll, pontokkal elválasztva. A header típust és algoritmust nevez meg, a payload JSON claims-et tartalmaz, az aláírás pedig az első két encoded szegmens pontos bájtjait védi.

A Base64URL csak átviteli kódolás. A header és payload titkos kulcs nélkül dekódolható, ezért jelszó és bizalmas profiladat nem való bele.

Az aláírás integritást és kulcskapcsolatot bizonyít

Szimmetrikus algoritmusnál a kibocsátó és verifier ugyanazt a secretet használja. Aszimmetrikus modellben a kibocsátó privát kulccsal ír alá, a szolgáltatások pedig publikus kulccsal ellenőriznek.

Az érvényes signature csak azt igazolja, hogy az adatok egy adott kulcshoz tartoznak. Az alkalmazásnak külön kell eldöntenie, megbízható-e a kulcs tulajdonosa és engedélyezett-e az algoritmus.

A szabványos claims közös szókincset ad

Az iss a kibocsátó, a sub az alany, az aud a célközönség, az exp a lejárat, az nbf a használhatóság kezdete. A formátum nem teszi mindet kötelezővé, a biztonsági profil igen.

Audience check nélkül egy másik szolgáltatásnak kiadott token is elfogadhatóvá válhat. Issuer check kizárja az ismeretlen autoritást, az időclaims csökkentik a lopott credential élettartamát.

A lokális ellenőrzés elosztott rendszernél előny

Egy API session lookup nélkül validálhatja a tokent. A publikus kulcs sok szolgáltatáshoz eljuthat anélkül, hogy bármelyik új tokeneket írhatna alá.

Az önállóság ára a revokáció. Egy már kiadott token a lejáratig régi jogosultságot állíthat. Rövid access lifetime, refresh flow és célzott revokáció szükséges.

Az aláírás és a titkosítás más problémát old meg

A legtöbb API JWT aláírt, nem titkosított. A payload olvasható, az aláírás a módosítást jelzi. A JWE elrejtheti a claims-et, de további kulcs- és interoperabilitási döntést hoz.

A titkosítás sem indokol túl sok adatot a tokenben. Egy ellopott encrypted bearer token továbbra is használható lehet.

A claims a kibocsátás után azonnal öregedni kezd

Szerepkör, tenantállapot vagy fióktiltás megváltozhat egy másodperccel később. A self-contained token erről nem értesül. Kockázatos művelethez aktuális lookup vagy rövid expiráció kellhet.

A payload csak stabil és szükséges információt hordozzon. A nagy token minden requesttel utazik, fejlécméretet növel és személyes adatot másol több rendszerbe.

A bearer token teljes értékű credential

Az aláírás nem azonosítja azt, aki éppen bemutatja a tokent. A legtöbb access token birtoklás alapján működik. Logba, URL-be vagy support ticketbe kerülve felhasználható.

TLS, rövid lifetime és Authorization fejléc redakció alapkövetelmény. A böngészős tárolás XSS, CSRF és doménarchitektúra alapján választandó.

Az ellenőrzés konfigurációból indul

A verifier nem fogadhatja el automatikusan a headerben kért algoritmust. Saját allowlistet használ issuer és key szerint. A kid csak kontrollált kulcskészletből választhat.

Signature után issuer, audience, idő, tenant és doménclaims következik. A külső hiba ne áruljon el kriptográfiai részletet, a belső log pedig ne tárolja a teljes tokent.

A kulcsrotáció átfedést igényel

A kibocsátó egyértelmű azonosítóval publikálja az aktuális ellenőrző kulcsokat. A korábbi kulcs addig marad elérhető, amíg a vele aláírt tokenek lejárnak.

A verifier cache frissül, de rövid endpoint-kiesésnél nem állítja le az egész rendszert. Kompromittált kulcsot ugyanakkor gyorsan ki kell vonni.

A token szerződésének változása elosztott rollout

Új kötelező claim, audience vagy issuer minden fogadót érint. Először a verifier válik kompatibilissé, utána a kibocsátó kezd új alakot adni, végül telemetry alapján lezárható a régi út.

A biztonsági szigorítás nem okozhat vakon teljes leállást, de a régi engedékeny forma sem maradhat örökre. A rolloutnak tulajdonosa és befejezési feltétele legyen.

A proof-of-possession külön fenyegetést kezel

Magas kockázatnál a token klienskulcshoz vagy TLS tanúsítványhoz köthető. A request további bizonyítékot hordoz, így a pusztán ellopott bearer token nem elegendő.

Ez kulcs-helyreállítást, replay-védelmet és eszközéletciklust bonyolít. Csak világos threat model alapján érdemes bevezetni.

A claims megosztása adatvédelmi döntés

Egy identity provider ugyanazt a felhasználót több alkalmazásnak is bemutathatja, de nem minden kliensnek kell ugyanaz az e-mail, csoportlista vagy belső azonosító. A scope és consent szabályozza, milyen állítás kerülhet az adott audience tokenjébe.

A pairwise subject identifier csökkentheti a szolgáltatások közötti automatikus korrelációt. A token nem válhat kényelmi okból hordozható teljes profil-adatbázissá. A kibocsátó dokumentálja a claims célját, retention hatását és azt, melyik rendszer az autoritatív forrás.

A refresh token más védelmi profilt igényel

A refresh token hosszabb életű, és új access tokeneket szerezhet, ezért lopása súlyosabb lehet. Rotációkor minden használat új tokent ad, a korábbi pedig érvénytelenné válik. Egy régi token újbóli megjelenése reuse detection esemény.

A token family visszavonható, és eszközhöz vagy sessionhöz köthető. A refresh credential nem kerülhet ugyanabba a széles körben elérhető log- és szolgáltatási útba, mint a rövid access token.

A JWT aláírt üzenet, nem mágikus identitás

A formátum akkor hasznos, amikor több fogadó hordozható, önállóan ellenőrizhető claims-et igényel. Nem szünteti meg a revokációt, a session lifecycle-t vagy az objektumszintű authorizationt.

A tartalom olvasható, az érvényesség kontextusfüggő, a birtoklás hozzáférést adhat. Ezzel a mentális modellel a JWT jó építőelem, nélküle csak bonyolult string, amelyben az alkalmazás túl könnyen megbízik.