close

JSON Web Token

Gå till navigering Gå till sök

JSON Web Token ( JWT ) är en öppen standard ( RFC 7519 ) för att skapa åtkomsttokens baserat på JSON - formatet . Används vanligtvis för att överföra data för autentisering i klient-serverapplikationer. Tokens skapas av servern, signeras med en hemlig nyckel och överförs till klienten, som sedan använder denna token för att verifiera sin identitet.

Historik

2011 bildades JOSE-gruppen (JSON Object Signing and Encryption group), vars syfte var att standardisera integritetsskyddsmekanismen, kryptering, samt formatet på nycklar och autentiseringsalgoritmer för att säkerställa interoperabilitet för säkerhetstjänster som använder JSON formatera. År 2013 dök informella konturer och exempel på användningen av denna grupps idéer upp i det offentliga området, som senare blev RFC -standarder : JWT, JWS, JWE, JWK och JWA.

JWT standardiserades officiellt av IETF i maj 2015. [ett]

Struktur

JWT-tokenet består av tre delar: rubrik (huvud), nyttolast (nyttolast) och signatur- eller krypteringsdata. De två första elementen är JSON-objekt med en viss struktur. Det tredje elementet beräknas utifrån de första och beror på den valda algoritmen (det kan utelämnas om en osignerad JWT används). Tokens kan omkodas till en kompakt representation (JWS/JWE Compact Serialization): Base64-URL- kodningsalgoritmen appliceras på rubriken och nyttolasten , varefter en signatur läggs till och alla tre elementen separeras med punkter ("." ).

Till exempel, för en rubrik och nyttolast som ser ut så här:

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

Vi får följande kompakta representation (nya rader läggs till för tydlighetens skull):

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIEdvbGQiLCJhZG1pbiI6dHJ1ZX0K.
LIHjWCBORSWMEibq-tnT8ue_deUqZx1K0XxCOXZRrBI

Titel

Rubriken innehåller nödvändig information för att beskriva själva token.

Det finns bara en nödvändig nyckel här:

  • alg: algoritmen som används för signering / kryptering (i fallet med en osignerad JWT används värdet " ingen ").

Valfria nycklar:

  • typ: typen av token ( typ ). Används när tokens blandas med andra objekt som har JOSE-rubriker. Måste vara " JWT ".
  • cty : innehållstyp . Om token innehåller användarnycklar utöver de registrerade tjänstnycklarna, bör denna nyckel inte finnas. Annars bör det vara " JWT " [2]

Nyttolast

Det här avsnittet innehåller användarinformation (till exempel användarnamn och åtkomstnivå), och vissa servicenycklar kan också användas. Alla är valfria:

  • iss: En skiftlägeskänslig sträng eller URI som är den unika identifieraren för den part som genererar token ( utfärdare ).
  • sub: En skiftlägeskänslig sträng eller URI som är den unika identifieraren för den part som denna token innehåller information om ( ämne ). Värden med denna nyckel måste vara unika inom ramen för den part som genererar JWT.
  • aud: En matris med skiftlägeskänsliga strängar eller URI:er som är en lista över mottagarna av den givna token. När den mottagande sidan tar emot en JWT med den givna nyckeln måste den kontrollera om sig själv finns i mottagarna - annars ignorera token ( publik ).
  • exp: En tid i Unix Time -format som avgör när token kommer att bli ogiltigt ( utgång ).
  • nbf: till skillnad från exp-nyckeln är detta en Unix-tid som avgör när token blir giltig ( inte före ).
  • jti: En sträng som anger den unika identifieraren för denna token ( JWT ID ). [3]
  • iat: tid i Unix Time -format som anger när token skapades. iat och nbf kanske inte matchar, till exempel om token skapades tidigare än den tidpunkt då den skulle bli giltig ( utfärdad på ).

Användning i klient-serverapplikationer

Få åtkomst till och uppdatera tokens

  • En åtkomsttoken är en token som ger sin ägare åtkomst till säkra serverresurser. Den har vanligtvis en kort livslängd och kan innehålla ytterligare information såsom IP-adressen till den part som begär token.
  • Uppdatera token är en token som tillåter klienter att begära nya åtkomsttoken efter att deras livstid har löpt ut. Dessa tokens utfärdas vanligtvis under en lång tidsperiod.

Arbetsschema

Som regel, när du använder JSON-tokens i klient-serverapplikationer, implementeras följande schema:

  1. Klienten autentiseras i applikationen (till exempel med inloggning och lösenord)
  2. Vid framgångsrik autentisering skickar servern åtkomst- och uppdateringstoken till klienten.
  3. Vid ytterligare åtkomst till servern använder klienten en åtkomsttoken. Servern kontrollerar tokens giltighet och ger klienten åtkomst till resurser
  4. Om åtkomsttoken blir ogiltig skickar klienten en uppdateringstoken, som svar på vilken servern tillhandahåller två uppdaterade tokens.
  5. Om uppdateringstoken blir ogiltig måste klienten återigen gå igenom autentiseringsprocessen (klausul 1). [fyra]

Fördelar

JWT har ett antal fördelar jämfört med metoden att lagra utfärdade sessioner på servern och i cookies på klientsidan:

  • När du använder JWT krävs ingen ytterligare data om utfärdade sessioner: allt som servern behöver göra är att verifiera signaturen.
  • Servern kanske inte är engagerad i skapandet av tokens, men tillhandahåller detta till externa tjänster.
  • JSON-tokens kan lagra ytterligare användbar information om användare. Resultatet är högre prestanda. När det gäller cookies är det ibland nödvändigt att begära mer information. När du använder JWT kan denna information skickas i själva token. [5]
  • JWT gör det möjligt att ge samtidig åtkomst till olika domäner och tjänster. [6] [7]

Möjliga attacker

Signaturborttagning

JSON-token består av tre delar, som är kodade oberoende av varandra. Således blir det möjligt att ta bort signaturen från token och ändra rubriken för att göra JWT osignerad. Om servern inte letar efter signaturen för token, kan en angripare ange sina egna värden i nyttolasten. Problemet löses genom att helt enkelt kassera osignerade objekt. [åtta]

CSRF

En av metoderna för att bekämpa CSRF är att lägga till speciella rubriker med krypterad information som bekräftar att begäran skickades från en betrodd server. Således, om JWT inte används som en cookie, blir en CSRF-attack omöjlig. [9]

XSS

JSON-tokens kan lagras i webbläsaren på två sätt: i DOM-lagring eller i cookies . I det första fallet kan systemet vara mottagligt för en XSS- attack, eftersom JavaScript har tillgång till DOM-lagringen och en angripare kan extrahera token därifrån för vidare användning för användarens räkning. När du använder cookies kan du ställa in HttpOnly-flaggan, som förhindrar JavaScript från att komma åt butiken. Således kommer angriparen inte att kunna extrahera token och applikationen blir skyddad från XSS. [tio]

JWS

Signerade JSON-tokens beskrivs av JWS-specifikationen ( RFC 7515 ).

Signaturalgoritmer som stöds

Signaturen för rubriken och nyttolasten utförs av följande algoritmer:

Algoritm som krävs för stöd av alla implementeringar:

Rekommenderade algoritmer:

Variationer av de rekommenderade algoritmerna som använder SHA-384 respektive SHA-512 stöds också:

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

Förkortningar i kursiv stil är namn som används i JSON-tokens enligt beskrivningen av JWA-specifikationen ( RFC 7518 ) [11]

Rubrikstruktur

I fallet med en signerad JWT kan ytterligare nycklar läggas till i rubriken:

  • jku: URI till uppsättningen offentliga nycklar i JSON-format som används för att signera denna token ( JSON Web Key Set URL ).
  • jwk: Nyckeln som används för att signera denna token ( JSON Web Key ).
  • kid: Den unika identifieraren för nyckeln som ska användas när en uppsättning nycklar ( nyckel-ID) anges.
  • x5u : URI för X.509- certifikatuppsättningen . Det första certifikatet i uppsättningen måste vara det som används för att signera denna token ( X.509 URL) .
  • x5c: En rad X.509-certifikat i JSON-format som används för att signera denna token ( X.509-certifikatkedja) .
  • x5t: X.509 - certifikat SHA-1 fingeravtryck .
  • crit: En array av strängar med namnen på de givna huvudnycklarna som ska analyseras av JWT-parsern. Om alla nycklar måste bearbetas används den inte ( kritiskt ). [12]

Implementeringar

JWT-implementationer finns i följande programmeringsspråk och ramverk: Clojure , .NET , Go , Haskell , Python , Java , JavaScript , Lua , Perl , PHP , Ruby , Rust , Scala , D , Erlang , Common Lisp och Elixir . [13]

Anteckningar

  1. JWT Handbook v0.13.0,  s.6-7 . auth0.com. Hämtad 11 december 2017. Arkiverad från originalet 15 juli 2018.
  2. Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), sid. 11  (engelska) . tools.ietf.org. Hämtad 20 december 2017. Arkiverad från originalet 16 juni 2019.
  3. Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), ca. 9-10  (engelska) . tools.ietf.org. Hämtad 20 december 2017. Arkiverad från originalet 16 juni 2019.
  4. JWT Handbook v0.13.0, c. 18  (engelska) . auth0.com. Hämtad 20 december 2017. Arkiverad från originalet 15 juli 2018.
  5. Ryan Boyd. Komma igång med OAuth 2.0 . - O'Reilly media, 2012. - S.  56 .
  6. JWT Handbook v0.13.0, sid. 9-11  (engelska) . auth0.com. Hämtad 21 december 2017. Arkiverad från originalet 15 juli 2018.
  7. Justin Richer och Antonio Sanso. OAuth 2 i aktion. - Manning Publications, 2017. - S. 252-253. — 360 s. — ISBN 9781617293276 .
  8. JWT Handbook v0.13.0, sid. 9  (engelska) . auth0.com. Hämtad 21 december 2017. Arkiverad från originalet 15 juli 2018.
  9. JWT Handbook v0.13.0, sid. 10  (engelska) . auth0.com. Hämtad 21 december 2017. Arkiverad från originalet 15 juli 2018.
  10. JWT Handbook v0.13.0, sid. 11-12  (engelska) . auth0.com. Hämtad 20 december 2017. Arkiverad från originalet 15 juli 2018.
  11. Bradley, John, Sakimura, Nat, Jones, Michael. JSON Web Token (JWT), sid. 16  (engelska) . tools.ietf.org. Hämtad 20 december 2017. Arkiverad från originalet 16 juni 2019.
  12. Bradley, John, Sakimura, Nat, Jones, Michael. JSON webbsignatur (JWS), c. 9-14  (engelska) . tools.ietf.org. Hämtad 20 december 2017. Arkiverad från originalet 12 september 2017.
  13. auth0.com. JWT.IO  (engelska) . jwt.io. Hämtad 20 december 2017. Arkiverad från originalet 25 oktober 2017.

Länkar