Webový token JSON

JSON Web Token ( JWT ) je otevřený standard ( RFC 7519 ) pro vytváření přístupových tokenů založených na formátu JSON . Obvykle se používá k přenosu dat pro ověřování v aplikacích klient-server. Tokeny jsou vytvářeny serverem, podepisovány tajným klíčem a přenášeny klientovi, který pak tento token používá k ověření své identity.

Historie

V roce 2011 byla vytvořena skupina JOSE (skupina JSON Object Signing and Encryption), jejímž účelem bylo standardizovat mechanismus ochrany integrity, šifrování a také formát klíčů a autentizačních algoritmů pro zajištění interoperability bezpečnostních služeb využívajících JSON. formát. V roce 2013 se ve veřejné doméně objevily neformální náčrty a příklady využití myšlenek této skupiny, které se později staly standardy RFC : JWT, JWS, JWE, JWK a JWA.

JWT byl oficiálně standardizován IETF v květnu 2015. [jeden]

Struktura

Token JWT se skládá ze tří částí: hlavičky (záhlaví), datové části (payload) a dat podpisu nebo šifrování. První dva prvky jsou objekty JSON určité struktury. Třetí prvek je vypočítán na základě prvních a závisí na zvoleném algoritmu (lze jej vynechat, pokud je použit JWT bez znaménka). Tokeny lze znovu zakódovat do kompaktní reprezentace (JWS/JWE Kompaktní serializace): na záhlaví a datovou část se použije kódovací algoritmus Base64-URL , poté se přidá podpis a všechny tři prvky se oddělí tečkami ("." ).

Například pro záhlaví a užitečné zatížení, které vypadá takto:

{ "alg" : "HS512" , "typ" : "JWT" ​​​​} { "sub" : "12345" , "name" : "John Gold" , "admin" : true }

Získáme následující kompaktní reprezentaci (pro přehlednost jsou přidány nové řádky):

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIEdvbGQiLCJhZG1pbiI6dHJ1ZX0K. LIHjWCBORSWMEibq-tnT8ue_deUqZx1K0XxCOXZRrBI

Název

Záhlaví obsahuje potřebné informace k popisu samotného tokenu.

Zde je vyžadován pouze jeden klíč:

Volitelné klíče:

  • typ: typ tokenu ( typ ). Používá se, když jsou tokeny smíchány s jinými objekty, které mají záhlaví JOSE. Musí to být " JWT ".
  • cty: typ obsahu . Pokud token obsahuje kromě registrovaných servisních klíčů uživatelské klíče, pak by tento klíč neměl být přítomen. Jinak by mělo být " JWT " [2]

Užitečné zatížení

Tato část obsahuje informace o uživateli (například uživatelské jméno a úroveň přístupu) a lze také použít některé servisní klíče. Všechny jsou volitelné:

  • iss: Řetězec nebo URI rozlišující malá a velká písmena , který je jedinečným identifikátorem strany generující token ( emitent ).
  • sub: Řetězec nebo URI rozlišující malá a velká písmena, který je jedinečným identifikátorem strany, o které tento token obsahuje informace ( předmět ). Hodnoty s tímto klíčem musí být jedinečné v kontextu strany generující JWT.
  • aud: Pole řetězců nebo URI rozlišujících velká a malá písmena, které je seznamem příjemců daného tokenu. Když přijímající strana obdrží JWT s daným klíčem, musí zkontrolovat svou přítomnost v příjemcích – jinak token ( audience ) ignorovat.
  • exp: Čas ve formátu Unix Time , který určuje, kdy se token stane neplatným ( expirace ).
  • nbf: na rozdíl od klíče exp se jedná o Unixový čas , který určuje, kdy se token stane platným ( ne dříve ).
  • jti: Řetězec, který určuje jedinečný identifikátor pro tento token ( JWT ID ). [3]
  • iat: čas ve formátu Unix Čas označující okamžik vytvoření tokenu. iat a nbf se nemusí shodovat, například pokud byl token vytvořen dříve, než by měl nabýt platnosti ( vydán v ).

Použití v aplikacích klient-server

Přístup a obnovení tokenů

  • Přístupový token je token, který uděluje svému vlastníkovi přístup k zabezpečeným prostředkům serveru. Obvykle má krátkou životnost a může nést další informace, jako je IP adresa strany požadující token.
  • Obnovovací token je token, který umožňuje klientům žádat o nové přístupové tokeny po vypršení jejich životnosti. Tyto tokeny jsou obvykle vydávány na dlouhou dobu.

Schéma práce

Při použití tokenů JSON v aplikacích klient-server je zpravidla implementováno následující schéma:

  1. Klient je v aplikaci autentizován (například pomocí přihlašovacího jména a hesla)
  2. V případě úspěšné autentizace server odešle klientovi přístupové a obnovovací tokeny.
  3. Při dalším přístupu na server klient používá přístupový token. Server zkontroluje platnost tokenu a poskytne klientovi přístup ke zdrojům
  4. Pokud se přístupový token stane neplatným, klient odešle obnovovací token, na který server poskytne dva obnovené tokeny.
  5. Pokud se obnovovací token stane neplatným, musí klient znovu projít procesem ověřování (klauzule 1). [čtyři]

Výhody

JWT má oproti přístupu k ukládání vydaných relací na serveru a do cookies na straně klienta řadu výhod:

  • Při použití JWT není nutné ukládat žádná další data o vydaných relacích: server musí pouze ověřit podpis.
  • Server se nemusí podílet na vytváření tokenů, ale poskytuje je externím službám.
  • Tokeny JSON mohou ukládat další užitečné informace o uživatelích. Výsledkem je vyšší výkon. V případě souborů cookie je někdy nutné požádat o další informace. Při použití JWT lze tyto informace předávat v samotném tokenu. [5]
  • JWT umožňuje poskytovat simultánní přístup k různým doménám a službám. [6] [7]

Možné útoky

Odstranění podpisu

Token JSON se skládá ze tří částí, které jsou kódovány nezávisle na sobě. Je tedy možné odstranit podpis z tokenu a změnit hlavičku tak, aby byl JWT nepodepsaný. Pokud server nezkontroluje podpis tokenu, může útočník zadat své vlastní hodnoty v datové části. Problém je vyřešen jednoduchým vyřazením nepodepsaných objektů. [osm]

CSRF

Jednou z metod boje proti CSRF je přidání speciálních hlaviček se zašifrovanými informacemi potvrzujícími, že požadavek byl odeslán z důvěryhodného serveru. Pokud se tedy JWT nepoužívá jako cookie, útok CSRF se stává nemožným. [9]

XSS

Tokeny JSON lze v prohlížeči uložit dvěma způsoby: v úložišti DOM nebo v souborech cookie . V prvním případě může být systém náchylný k XSS útoku, protože JavaScript má přístup k úložišti DOM a útočník odtud může extrahovat token pro další použití jménem uživatele. Při používání cookies si můžete nastavit příznak HttpOnly, který zabrání JavaScriptu v přístupu do obchodu. Útočník tak nebude moci extrahovat token a aplikace bude chráněna před XSS. [deset]

JWS

Podepsané tokeny JSON jsou popsány specifikací JWS ( RFC 7515 ).

Podporované podpisové algoritmy

Podpis hlavičky a užitečného zatížení se provádí pomocí následujících algoritmů:

Algoritmus požadovaný pro podporu všemi implementacemi:

Doporučené algoritmy:

Podporovány jsou také varianty doporučených algoritmů používajících SHA-384 a SHA-512:

  • HS384, HS512
  • RS384 , RS512
  • ES384 , ES512

Zkratky uvedené kurzívou jsou názvy používané v tokenech JSON, jak je popsáno ve specifikaci JWA ( RFC 7518 ) [11]

Struktura záhlaví

V případě podepsaného JWT lze do záhlaví přidat další klíče:

  • jku: URI sady veřejných klíčů ve formátu JSON používaných k podepsání tohoto tokenu ( JSON Web Key Set URL ).
  • jwk: Klíč používaný k podepsání tohoto tokenu ( Webový klíč JSON ).
  • kid: Jedinečný identifikátor klíče, který se má použít, když je zadána sada klíčů ( ID klíče).
  • x5u : Identifikátor URI pro sadu certifikátů X.509 . První certifikát v sadě musí být ten, který byl použit k podepsání tohoto tokenu ( X.509 URL) .
  • x5c: Pole certifikátů X.509 ve formátu JSON použité k podpisu tohoto tokenu ( řetěz certifikátů X.509) .
  • x5t: certifikát X.509 SHA-1 otisk prstu .
  • crit: Pole řetězců se jmény daných klíčů záhlaví, které mají být analyzovány analyzátorem JWT. Pokud musí být zpracovány všechny klíče, pak se nepoužívá ( kritické ). [12]

Implementace

Implementace JWT existují v následujících programovacích jazycích a frameworkech: Clojure , .NET , Go , Haskell , Python , Java , JavaScript , Lua , Perl , PHP , Ruby , Rust , Scala , D , Erlang , Common Lisp a Elixir . [13]

Poznámky

  1. ↑ Příručka JWT v0.13.0,  str . 6-7 . auth0.com. Získáno 11. prosince 2017. Archivováno z originálu 15. července 2018.
  2. ↑ Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), str. 11  (anglicky) . tools.ietf.org. Získáno 20. prosince 2017. Archivováno z originálu 16. června 2019.
  3. ↑ Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), c. 9-10  (anglicky) . tools.ietf.org. Získáno 20. prosince 2017. Archivováno z originálu 16. června 2019.
  4. ↑ Příručka JWT v0.13.0, c. 18  (anglicky) . auth0.com. Získáno 20. prosince 2017. Archivováno z originálu 15. července 2018.
  5. ↑ Ryan Boyd. Začínáme s protokolem OAuth 2.0 . - O'Reilly media, 2012. - S.  56 .
  6. ↑ Příručka JWT v0.13.0, str. 9-11  (anglicky) . auth0.com. Staženo 21. prosince 2017. Archivováno z originálu 15. července 2018.
  7. ↑ Justin Richer a Antonio Sanso. OAuth 2 v akci. - Manning Publications, 2017. - S. 252-253. - 360 s. — ISBN 9781617293276 .
  8. ↑ Příručka JWT v0.13.0, str. 9  (anglicky) . auth0.com. Staženo 21. prosince 2017. Archivováno z originálu 15. července 2018.
  9. ↑ Příručka JWT v0.13.0, str. 10  (anglicky) . auth0.com. Staženo 21. prosince 2017. Archivováno z originálu 15. července 2018.
  10. ↑ Příručka JWT v0.13.0, str. 11-12  (anglicky) . auth0.com. Získáno 20. prosince 2017. Archivováno z originálu 15. července 2018.
  11. ↑ Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), str. 16  (anglicky) . tools.ietf.org. Získáno 20. prosince 2017. Archivováno z originálu 16. června 2019.
  12. ↑ Bradley, John, Sakimura, Nat, Jones, Michael. Webový podpis JSON (JWS), c. 9-14  (anglicky) . tools.ietf.org. Získáno 20. prosince 2017. Archivováno z originálu 12. září 2017.
  13. ↑ auth0.com. JWT.IO  (anglicky) . jwt.io. Získáno 20. prosince 2017. Archivováno z originálu 25. října 2017.

Odkazy