Vad är JSON Web Token (JWT)?
Få en klar förståelse av grunderna för JSON Web Token (JWT) på 5 minuter.
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", ochtyp
ä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:
Header
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ändaRS384
ochRS512
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ändaES384
ochES512
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:
- Dela upp JWT i tre delar (header, payload och signatur) med
.
-avgränsaren. - Avkoda header och payload med Base64URL.
- 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).