introduktion till JSON Web Tokens

nytt: få JWT-handboken gratis och lär dig JWTs på djupet!

Vad är JSON Web Token?

JSON Web Token (JWT) är en öppen standard (RFC 7519) som definierar en kompakt och fristående sätt för att säkert överföra information mellan parter som ett JSON-objekt. Denna information kan verifieras och lita på eftersom den är digitalt signerad. JWTs kan signeras med en hemlighet (med hmac-algoritmen) eller ett offentligt/privat nyckelpar med RSA eller ECDSA.,

Även om JWTs kan krypteras för att också ge sekretess mellan parter, kommer vi att fokusera på signerade tokens. Signerade tokens kan verifiera integriteten hos de påståenden som finns i den, medan krypterade tokens döljer dessa påståenden från andra parter. När tokens signeras med offentliga/privata nyckelpar intygar signaturen också att endast den part som innehar den privata nyckeln är den som undertecknade den.

När ska du använda JSON Web Polletter?

här är några scenarier där JSON Web Tokens är användbara:

• Authorization: Detta är det vanligaste scenariot för att använda JWT., När användaren är inloggad kommer varje efterföljande begäran att innehålla JWT, så att användaren kan komma åt rutter, tjänster och resurser som är tillåtna med den token. Single Sign On är en funktion som ofta använder JWT nuförtiden, på grund av dess små overhead och dess förmåga att enkelt användas över olika domäner.

• informationsutbyte: JSON Web Tokens är ett bra sätt att säkert överföra information mellan parter. Eftersom JWTs kan signeras—till exempel med offentliga/privata nyckelpar—kan du vara säker på att avsändarna är de som de säger att de är., Eftersom signaturen beräknas med rubriken och nyttolasten kan du också kontrollera att innehållet inte har manipulerats.

Vad är JSON Web Token-strukturen?

i sin kompakta form består JSON Web Tokens av tre delar åtskilda av prickar (.), som är:

• Header
• nyttolast
• signatur

därför ser en JWT vanligtvis ut som följande.

xxxxx.yyyyy.zzzzz

låt oss bryta ner de olika delarna.,

Header

huvudet består vanligtvis av två delar: typen av token, som är JWT, och signeringsalgoritmen som används, till exempel HMAC SHA256 eller RSA.

till exempel:

{ "alg": "HS256", "typ": "JWT"}

då är denna JSON Base64Url kodad för att bilda den första delen av JWT.

nyttolast

den andra delen av token är nyttolasten, som innehåller kraven. Fordringar är uttalanden om ett företag (vanligtvis användaren) och ytterligare data.Det finns tre typer av fordringar: registrerade, offentliga och privata fordringar.,

• registrerade fordringar: dessa är en uppsättning fördefinierade fordringar som inte är obligatoriska men rekommenderade, för att ge en uppsättning användbara, driftskompatibla fordringar. Några av dem är: iss (emittent), exp (utgångsdatum), sub (ämne), aud (publik) och andra.

  Observera att anspråksnamnen endast är tre tecken så länge JWT är tänkt att vara kompakt.

• offentliga anspråk: dessa kan definieras efter behag av dem som använder JWTs., Men för att undvika kollisioner bör de definieras i IANA JSON Web Token-registret eller definieras som en URI som innehåller ett kollisionsbeständigt namnområde.

• privata anspråk: det här är de anpassade anspråk som skapats för att dela information mellan parter som samtycker till att använda dem och är varken registrerade eller offentliga anspråk.

ett exempel på nyttolast kan vara:

{ "sub": "1234567890", "name": "John Doe", "admin": true}

nyttolasten är sedan Base64Url kodad för att bilda den andra delen av JSON Web Token.,

Observera att för signerade tokens är denna information, även om den är skyddad mot manipulering, läsbar av någon. Lägg inte hemlig information i nyttolasten eller header-elementen i en JWT om den inte är krypterad.

signatur

för att skapa signaturdelen måste du ta den kodade rubriken, den kodade nyttolasten, en hemlighet, algoritmen som anges i rubriken och underteckna den.,

om du till exempel vill använda HMAC SHA256-algoritmen skapas signaturen på följande sätt:

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

signaturen används för att verifiera att meddelandet inte ändrades längs vägen, och när det gäller tokens signerade med en privat nyckel kan den också verifiera att avsändaren av JWT är den som den säger att den är.

att sätta ihop alla

utgången är tre Base64-URL strängar separerade med punkter som lätt kan överföras i HTML-och HTTP-miljöer, samtidigt som den är mer kompakt jämfört med XML-baserade standarder som SAML.,

följande visar en JWT som har föregående rubrik och nyttolast kodad, och den är signerad med en hemlighet.

om du vill spela med JWT och omsätta dessa begrepp i praktiken kan du använda jwt.io Debugger att avkoda, verifiera och generera JWTs.

hur fungerar JSON Web Tokens?

vid autentisering kommer en JSON-Webbtoken att returneras när användaren loggar in med sina autentiseringsuppgifter. Eftersom tokens är referenser måste stor försiktighet vidtas för att förhindra säkerhetsproblem., I allmänhet bör du inte hålla tokens längre än vad som krävs.

Du bör inte heller lagra känsliga sessionsdata i webbläsarlagring på grund av bristande säkerhet.

När användaren vill komma åt en skyddad rutt eller resurs, ska användaragenten skicka JWT, vanligtvis i Auktoriseringsrubriken med Bärarschemat. Innehållet i rubriken ska se ut som följande:

Authorization: Bearer <token>

detta kan i vissa fall vara en statslös auktoriseringsmekanism., Serverns skyddade rutter kommer att söka efter en giltig JWT i Authorization – rubriken, och om den är närvarande får användaren tillgång till skyddade resurser. Om JWT innehåller nödvändiga uppgifter kan behovet av att fråga databasen för vissa operationer minskas, även om detta kanske inte alltid är fallet.

om token skickas iAuthorization – huvudet, kommer Cross-Origin Resource Sharing (CORS) inte att vara ett problem eftersom det inte använder cookies.,

Följande diagram visar hur en JWT erhålls och används för att komma åt API: er eller resurser:

1. ansökan eller klienten begär tillstånd till auktoriseringsservern. Detta utförs genom ett av de olika auktoriseringsflödena. Till exempel kommer en typisk OpenID Connect-kompatibel webbapplikation att gå igenom /oauth/authorize slutpunkt med hjälp av auktoriseringskodflödet.
2. när auktoriseringen beviljas returnerar auktoriseringsservern en åtkomsttoken till programmet.,
3. programmet använder åtkomsttoken för att komma åt en skyddad resurs (som ett API).

Observera att med signerade tokens är all information som finns i token utsatt för användare eller andra parter, även om de inte kan ändra den. Det betyder att du inte ska lägga hemlig information i token.

Varför ska vi använder JSON Web Polletter?

Låt oss tala om fördelarna med JSON Web Polletter (JWT) jämfört med Enkla Web-Tokens (SWT) och Security Assertion Markup Language Polletter (SAML).,

eftersom JSON är mindre verbose än XML, när den är kodad dess storlek är också mindre, vilket gör JWT mer kompakt än SAML. Detta gör JWT ett bra val att skickas i HTML och HTTP miljöer.

säkerhetsmässigt kan SWT endast signeras symmetriskt av en delad hemlighet med hjälp av HMAC-algoritmen. JWT och SAML-tokens kan dock använda ett offentligt / privat nyckelpar i form av ett X. 509-certifikat för signering. Att signera XML med XML Digital signatur utan att införa dunkla säkerhetshål är mycket svårt jämfört med enkelheten att signera JSON.,

JSON parsers är vanliga i de flesta programmeringsspråk eftersom de mappar direkt till objekt. Omvänt har XML inte en naturlig dokument-till-objekt-mappning. Detta gör det lättare att arbeta med JWT än SAML påståenden.

När det gäller användning används JWT på Internet skala. Detta belyser enkel klientbaserad bearbetning av JSON Web token på flera plattformar, särskilt mobila.,

Jämförelse av längden av en kodad JWT och en kodad SAML

Om du vill läsa mer om JSON Web Polletter och även börja använda dem för att utföra autentisering i dina egna program, bläddra till JSON Web-Token målsida på Auth0.