Svenska
  • jwt
  • auth
  • authentication
  • identity
  • api
  • openid
  • oauth

Vad är JSON Web Token (JWT)?

Få en klar förståelse av grunderna för JSON Web Token (JWT) på 5 minuter.

Gao
Gao
Founder

JSON Web Token (JWT) används i stor utsträckning i moderna webbapplikationer och öppna standarder som OpenID Connect, vilket underlättar autentisering och auktorisering. Även om den officiella RFC 7519 fungerar som en viktig referens kan den vara utmanande för nybörjare att förstå. I den här artikeln kommer vi att fokusera på de grundläggande koncepten för JWT och presentera dem i enkel språk med exempel.

Varför behöver vi JWT?

Nuförtiden är det ganska vanligt att använda JSON för att utbyta data mellan två parter. Tänk på ett JSON-objekt som representerar en användare:

sub är en förkortning för "subject", vilket är ett standard claim i OpenID Connect för att representera användaridentifieraren (användar-ID).

Hur kan vi garantera integriteten hos detta JSON-objekt? Med andra ord, hur kan vi försäkra oss om att datan inte har manipulerats under överföringen? En vanlig lösning är att använda digitala signaturer. Till exempel, vi kan använda offentlig-nyckel-kryptografi: servern signerar JSON-objektet med sin privata nyckel, och klienten kan verifiera signaturen med serverns offentliga nyckel.

Kort sagt erbjuder JWT ett standardiserat tillvägagångssätt för att representera JSON-objektet och dess signatur.

Formatet av JWT

Eftersom det finns många algoritmer för att skapa digitala signaturer är det nödvändigt att specificera algoritmen som används för JWT-signering. Detta uppnås genom att konstruera ett JSON-objekt:

alg är en förkortning för "algorithm", och typ är en förkortning för "type".

Vanligtvis sätts typ till JWT i versaler. För vårt exempel är alg HS256, vilket står för HMAC-SHA256 (vi kommer att förklara det snart), och indikerar att vi använder denna algoritm för att skapa signaturen.

Nu har vi alla ingredienser för en JWT:

  • Header JSON: Algoritm och typ
  • Payload JSON: Den faktiska datan
  • Signatur: Signaturen som omfattar header och payload

Emellertid är vissa tecken som mellanslag och radbrytningar inte vänliga för nätverkstransmission. Därför behöver header och payload vara Base64URL-kodade. Den typiska JWT ser ut så här:

. fungerar som avgränsare.

Låt oss sätta ihop allt och skapa en JWT:

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

Base64URL-kodad: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

JSON: {"sub":"foo","name":"John Doe"}

Base64URL-kodad: eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ

Signatur

I HMAC-SHA256 skapas signaturen med en hemlighet:

Till exempel, med hemligheten som some-great-secret, blir signaturen: XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g.

JWT

Den slutliga JWT är:

Denna giltiga JWT kan verifieras av vilken part som helst som innehar hemligheten.

Välj signeringsalgoritmen

Som nämnts tidigare finns det olika algoritmer för att skapa digitala signaturer. Vi använde HS256 som exempel, men den kanske inte är tillräckligt stark eftersom hemligheten måste delas mellan parterna (t.ex. klienten och servern).

I verkliga scenarier kan klienter inkludera offentliga applikationer som React-appar som inte kan hålla hemligheten säker. Följaktligen innebär den föredragna metoden att använda offentlig-nyckel-kryptografi (dvs. asymmetrisk kryptografi) för att signera JWT. Låt oss börja med den mest populära algoritmen: RSA.

RSA

RSA, en asymmetrisk algoritm, använder ett par nycklar: en offentlig nyckel och en privat nyckel. Den offentliga nyckeln används för att verifiera signaturen, medan den privata nyckeln används för signering.

Header JSON för RSA ser ut så här:

RS256 står för RSA-SHA256, vilket innebär att signaturen skapas med RSA-algoritmen och SHA256-hashfunktionen. Du kan också använda RS384 och RS512 för att skapa signaturer med SHA384 och SHA512-hashfunktioner, respektive.

Signaturen skapas med den privata nyckeln:

Återigen kan vi sätta ihop dessa delar för att skapa en JWT, och den slutliga JWT ser ut så här:

Nu kan klienten verifiera signaturen utan att känna till den privata nyckeln.

ECDSA

Även om RSA är allmänt antaget lider den av större signaturstorlekar, ibland överstiger kombinerade storlek av header och payload. Elliptic Curve Digital Signature Algorithm (ECDSA) är en annan asymmetrisk algoritm som kan skapa mer kompakta signaturer och är mer presterande.

För att generera en privat nyckel för ECDSA behöver vi välja en kurva. Detta ligger utanför omfattningen av denna artikel, men du kan hitta mer information här.

Header JSON för ECDSA ser ut så här:

ES256 står för ECDSA-SHA256, vilket innebär att signaturen skapas med ECDSA-algoritmen och SHA256-hashfunktionen. Du kan också använda ES384 och ES512 för att skapa signaturer med SHA384 och SHA512-hashfunktionen, respektive.

Signaturen skapas med den privata nyckeln:

Den slutliga JWT behåller samma struktur som RSA men med en avsevärt kortare signatur:

Verifiera JWT

Att verifiera en JWT är enkelt som den omvända processen att skapa en JWT:

  1. Dela upp JWT i tre delar (header, payload och signatur) med .-avgränsaren.
  2. Avkoda header och payload med Base64URL.
  3. Verifiera signaturen med algoritmen som specificeras i headern och den offentliga nyckeln (för asymmetriska algoritmer).

Det finns många bibliotek tillgängliga för att hjälpa till med JWT-verifiering, till exempel jose för Node.js och webbläsare.

Slutsats

I den här artikeln förklarade vi kort de grundläggande koncepten för JWT, tillsammans med en översikt över hur man skapar och verifierar det. Många detaljer förblir outforskade, och vi kommer att täcka dem i framtida artiklar.

Logto utnyttjar öppna standarder som JWT och OpenID Connect för att säkra dina appar och API:er med förenklade arbetsflöden för varje utvecklare. Om du är intresserad kan du prova det gratis (inget kreditkort krävs).