Webový token JSON - JSON Web Token

Webový token JSON
PostaveníInternetový standard
Nejprve publikováno28. prosince 2010 (2010-12-28)
Nejnovější verzeRFC  7519
Květen 2015
OrganizaceIETF
ZkratkaJWT

Webový token JSON (JWT, někdy výrazné /dʒɒt/, stejné jako anglické slovo „jot“[1]) je internetový standard pro vytváření dat s volitelným podpisem a / nebo volitelným šifrováním, jehož užitečné zatížení platí JSON který uplatňuje určitý počet nároků. Tokeny jsou podepsány buď pomocí soukromého tajemství, nebo veřejného / soukromého klíče. Server by například mohl vygenerovat token, který má nárok „přihlášený jako správce“, a poskytnout jej klientovi. Klient by pak mohl použít tento token k prokázání, že je přihlášen jako správce. Tokeny lze podepsat soukromým klíčem jedné strany (obvykle server) aby tato strana mohla následně ověřit, zda je token legitimní. Pokud druhá strana vlastní vhodným a důvěryhodným způsobem odpovídající veřejný klíč, je také schopna ověřit legitimitu tokenu. The žetony jsou navrženy tak, aby byly kompaktní[2] URL -bezpečný,[3] a použitelné zejména v a webový prohlížeč jednotné přihlášení (SSO) kontext. Deklarace JWT lze obvykle použít k předání identity ověřených uživatelů mezi poskytovatel identity a a Poskytovatel služeb, nebo jakýkoli jiný typ nároků, jak to vyžadují obchodní procesy.[4][5]

JWT spoléhá na další standardy založené na JSON: Webový podpis JSON a Webové šifrování JSON.[1][6][7]

Struktura

Záhlaví
{  "alg": "HS256",  "typ": „JWT“}
Určuje, který algoritmus se používá ke generování podpisu

HS256 označuje, že tento token je podepsán pomocí HMAC-SHA256.

Typické použité kryptografické algoritmy jsou HMAC s SHA-256 (HS256) a RSA podpis s SHA-256 (RS256). JWA (webové algoritmy JSON) RFC 7518 zavádí mnoho dalších pro ověřování i šifrování.[8]

Užitečné zatížení
{  "Přihlášen jako": „admin“,  „iat“: 1422779638}
Obsahuje soubor nároků. Specifikace JWT definuje sedm jmen registrovaných nároků, které jsou standardní pole běžně součástí tokenů.[1] Obvykle jsou také zahrnuty vlastní deklarace, v závislosti na účelu tokenu.

V tomto příkladu je standardní požadavek Issued At Time (iat) a vlastní reklamace (Přihlášen jako).

Podpis
HMAC-SHA256(  tajný,  base64urlEncoding(záhlaví) + '.' +  base64urlEncoding(užitečné zatížení))
Bezpečně ověří token. Podpis se počítá kódováním záhlaví a užitečného zatížení pomocí Kódování Base64url a zřetězení dvou společně s oddělovačem období. Tento řetězec je poté spuštěn kryptografickým algoritmem uvedeným v záhlaví, v tomto případě HMAC-SHA256. The Kódování Base64url je podobný base64, ale používá různé nealfanumerické znaky a vynechává výplň.

Tyto tři části jsou kódovány samostatně pomocí Kódování Base64url a zřetězené pomocí období k vytvoření JWT:

konst žeton = base64urlEncoding(záhlaví) + '.' + base64urlEncoding(užitečné zatížení) + '.' + base64urlEncoding(podpis)

Výše uvedená data a tajemství „secretkey“ vytváří token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oCJRJRC5RJ

Tento výsledný token lze snadno předat HTML a HTTP.[3]

Použití

Při ověřování, když se uživatel úspěšně přihlásí pomocí svých přihlašovacích údajů, bude vrácen webový token JSON a musí být uložen místně (obvykle v místní nebo relační úložiště, ale cookies lze také použít), místo tradičního přístupu k vytvoření relace na serveru a vrácení souboru cookie. U bezobslužných procesů se klient může také autentizovat přímo generováním a podepsáním vlastního JWT s předem sdíleným tajemstvím a předáním do oAuth kompatibilní služba, jako je tato:

POST / oauth2 / token?Typ obsahu:aplikace/x-www-form-urlencodedgrant_type = urn: ietf: params: oauth: grant-type: jwt-bearer & assertion = eyJhb ...

Pokud klient předá platné tvrzení JWT, server vygeneruje přístupový_token platný pro volání aplikace a předá jej zpět klientovi:

{  „access_token“: „eyJhb ...“,  „token_type“: "Nosič",  "vyprší v": 3600}

Pokud chce klient získat přístup k chráněné trase nebo prostředku, měl by uživatelský agent odeslat JWT, obvykle v Oprávnění záhlaví pomocí Nosič schéma. Obsah záhlaví může vypadat takto:

Autorizace: Nositel eyJhbGci...  ...yu5CSpyHI

Toto je bezstavový ověřovací mechanismus, protože stav uživatele se nikdy neukládá do paměti serveru. Chráněné trasy serveru zkontrolují platný JWT v záhlaví Autorizace a pokud je k dispozici, bude uživateli povolen přístup k chráněným prostředkům. Protože JWT jsou samostatné, jsou zde všechny potřebné informace, což snižuje potřebu opakovaně dotazovat databázi.

Standardní pole

Internetové koncepty definují následující standardní pole („tvrzení“), která lze použít uvnitř sady deklarací JWT:

kódnázevpopis
jeVydavatelUrčuje jistinu, která vydala JWT.
subPředmětIdentifikuje předmět JWT.
audPublikumIdentifikuje příjemce, pro které je JWT určen. Každý ředitel zamýšlel zpracovat JWT musí identifikovat se s hodnotou v požadavku publika. Pokud se hlavní osoba zpracovávající reklamaci neidentifikuje s hodnotou v aud pokud je tento nárok přítomen, pak JWT musí být odmítnut.
expDoba platnostiUrčuje dobu vypršení platnosti a po které JWT nesmět být přijata ke zpracování. Hodnota musí být NumericDate:[9] celé číslo nebo desetinné číslo představující minulé sekundy 1970-01-01 00: 00: 00Z.
nbfNe předtímUrčuje čas, kdy JWT začne být přijímán ke zpracování. Hodnota musí být NumericDate.
iatVydáno vUrčuje čas, kdy byl JWT vydán. Hodnota musí být NumericDate.
jtiID JWTUnikátní identifikátor tokenu rozlišující velká a malá písmena i mezi různými emitenty.

V záhlaví JWT se běžně používají následující pole:

kódnázevpopis
typTyp tokenuPokud je k dispozici, doporučuje se nastavit na JWT.
ctyTyp obsahuPokud se používá vnořené podepisování nebo šifrování, doporučuje se nastavit na JWT; jinak toto pole vynechejte.[1]
algAlgoritmus ověřovacího kódu zprávyEmitent může volně nastavit algoritmus k ověření podpisu na tokenu. Některé podporované algoritmy jsou však nezabezpečené.[10]
dítěID klíčeNápověda označující, který klíč klient použil ke generování podpisu tokenu. Server porovná tuto hodnotu s klíčem v souboru, aby ověřil, že podpis je platný a token je autentický.
x5cŘetěz certifikátu x.509Řetěz certifikátů ve formátu RFC4945 odpovídající soukromému klíči použitému ke generování podpisu tokenu. Server použije tyto informace k ověření, že podpis je platný a token je autentický.
x5ux.509 URL řetězce certifikátůURL, kde může server načíst řetězec certifikátů odpovídající soukromému klíči použitému ke generování podpisu tokenu. Server načte a použije tyto informace k ověření, že podpis je autentický.
kritKritickýSeznam záhlaví, kterým musí server porozumět, aby mohl token přijmout jako platný


Implementace

Implementace JWT existují pro mnoho jazyků a rámců, mimo jiné včetně:

Zranitelnosti

Webové tokeny JSON mohou obsahovat stav relace. Pokud ale požadavky projektu umožňují zneplatnění relace před vypršením platnosti JWT, služby již nemohou důvěřovat tvrzením tokenu samotným tokenem. Chcete-li ověřit, že relace uložená v tokenu není odvolána, je nutné zkontrolovat tvrzení tokenů proti úložiště dat. To vykresluje tokeny, které již nejsou bez státní příslušnosti, což podkopává primární výhodu JWT.[36]

Bezpečnostní konzultant Tim McLean nahlásil chyby zabezpečení v některých knihovnách JWT, které používaly alg pole k nesprávnému ověření tokenů. I když byly tyto chyby zabezpečení opraveny, McLean navrhl ukončení podpory alg pole, aby se zabránilo podobným nejasnostem při provádění.[10]

Se správným designem mohou vývojáři řešit chyby zabezpečení algoritmu pomocí preventivních opatření:[37][38]

  1. Nikdy nedovolte, aby ověření ověřovala pouze hlavička JWT
  2. Znát algoritmy
  3. Použijte vhodnou velikost klíče

Architekt softwarového zabezpečení Kurt Rodarmer upozorňuje na další chyby zabezpečení designu JWT kolem kryptografických podpisových klíčů a významnou chybu zabezpečení, která odhaluje analyzátor JSON knihovny, aby otevřel útok.[39] Toto je přímý výsledek výběru JSON k vyjádření hlavičky tokenu a je obtížnější jej zmírnit.

Reference

  1. ^ A b C d Jones, Michael B .; Bradley, Bradley; Sakimura, Sakimura (květen 2015). Webový token JSON (JWT). IETF. doi:10.17487 / RFC7519. ISSN  2070-1721. RFC 7519.
  2. ^ Nikl, Jochen (2016). Zvládnutí správy identit a přístupu pomocí Microsoft Azure. str. 84. ISBN  9781785887888. Citováno 20. července 2018.
  3. ^ A b „JWT.IO - Úvod do webových tokenů JSON“. jwt.io. Citováno 20. července 2018.
  4. ^ Sevilleja, Chrisi. „Anatomie webového tokenu JSON“. Citováno 8. května 2015.
  5. ^ „Dokumentace Atlassian Connect“. developer.atlassian.com. Citováno 8. května 2015.
  6. ^ "draft-ietf-jose-json-web-signature-41 - webový podpis JSON (JWS)". tools.ietf.org. Citováno 8. května 2015.
  7. ^ „draft-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)“. tools.ietf.org. Citováno 8. května 2015.
  8. ^ "draft-ietf-jose-json-web-algorithms-40 - JSON Web Algorithms (JWA)". tools.ietf.org. Citováno 8. května 2015.
  9. ^ Jones, Michael B .; Bradley, Bradley; Sakimura, Sakimura (květen 2015). ""exp "(doba platnosti) nárok". Webový token JSON (JWT). IETF. sek. 4.1.4. doi:10.17487 / RFC7519. ISSN  2070-1721. RFC 7519.
  10. ^ A b McLean, Tim (31. března 2015). „Kritické chyby zabezpečení v knihovnách JSON Web Token“. Auth0. Citováno 29. března 2016.
  11. ^ jwt-dotnet na github.com
  12. ^ libjwt na github.com
  13. ^ "liquidz / clj-jwt". GitHub. Citováno 7. května 2018.
  14. ^ cljwt na github.com
  15. ^ [1] na github.com
  16. ^ "bryanjos / joken". GitHub. Citováno 7. května 2018.
  17. ^ „dgrijalva / jwt-go“. GitHub. Citováno 8. ledna 2018.
  18. ^ "jwt: JSON Web Token (JWT) dekódování a kódování". Hackování. Citováno 7. května 2018.
  19. ^ auth0 / java-jwt na github.com
  20. ^ „kjur / jsrsasign“. GitHub. Citováno 7. května 2018.
  21. ^ „SkyLothar / lua-resty-jwt“. GitHub. Citováno 7. května 2018.
  22. ^ „jsonwebtoken“. npm. Citováno 7. května 2018.
  23. ^ ocaml-jwt na github.com
  24. ^ Krypta :: JWT na cpan.org
  25. ^ lcobucci / jwt na github.com
  26. ^ Egan, Morten (7. února 2019), GitHub - morten-egan / jwt_ninja: PLSQL implementace webových tokenů JSON., vyvoláno 14. března 2019
  27. ^ "SP3269 / posh-jwt". GitHub. Citováno 1. srpna 2018.
  28. ^ „jpadilla / pyjwt“. GitHub. Citováno 21. března, 2017.
  29. ^ net-jwt na pkgs.racket-lang.org
  30. ^ JSON-WebToken na github.com
  31. ^ ruby-jwt na github.com
  32. ^ frank_jwt na github.com
  33. ^ [2] na github.com
  34. ^ jwt-scala na github.com
  35. ^ [3] na github.com
  36. ^ Slootweg, Sven. „Přestaňte používat JWT pro relace“. joepie91 Ramblings. Citováno 1. srpna 2018.
  37. ^ „Běžné chyby zabezpečení JWT a jak se jim vyhnout“. Citováno 14. května 2018.
  38. ^ Andreasi, Happe. „JWT: Signature vs MAC útoky“. snikt.net. Citováno 27. května 2019.
  39. ^ Rodarmer, Kurt (21. července 2019). „Obskurní chyby zabezpečení JWT“. rodarmer.com. Citováno 25. července 2019.

externí odkazy