Verifiera signaturen för en JSON Web Token (JWT)

Varför verifiera signaturen på en JWT?

En JSON Web Token (JWT) består av tre delar separerade med punkter: header.payload.signature. Att avkoda en JWT är helt enkelt att läsa de två första delarna (som är Base64URL). Vem som helst kan göra det, och vem som helst kan tillverka en JWT med vilken payload som helst. Det som gör en JWT värd att lita på är endast signaturen: utan verifiering är att acceptera en JWT som att släppa in hemma hos sig alla som påstår sig vara någon, utan att fråga efter legitimation.

Det här verktyget verifierar signaturen på en JWT utifrån en nyckel. Det nöjer sig inte med att avkoda: det räknar om signaturen utifrån headern, payloaden och din nyckel och jämför den sedan med tokenens signatur. Om de två stämmer överens är tokenen äkta. Annars har den förfalskats, modifierats eller signerats med en annan nyckel.

Verifiering är hörnstenen i varje arkitektur som använder JWT för autentisering eller auktorisering: utan giltig signatur kan payloaden ljuga. En angripare som ändrar "role":"user" till "role":"admin" skulle inte ha någon svårighet att göra det om servern bara kontrollerade tokenens format och inte signaturen.

Vanliga algoritmer

JWT-specifikationen (RFC 7518, JSON Web Algorithms) definierar flera algoritmfamiljer. Här är de mest använda i produktion:

• HMAC (HS256, HS384, HS512): symmetrisk signatur baserad på HMAC-SHA. Samma hemliga nyckel används för att signera och verifiera. Enkelt att sätta upp, prestandavänligt, men varje part som kan verifiera tokenen kan också utfärda den. Lämpligt för scenarier där utfärdare och verifierare är samma team eller samma tjänst.
• RSA (RS256, RS384, RS512): asymmetrisk signatur. Privat nyckel signerar, publik nyckel verifierar. Idealiskt när utfärdare och verifierare är olika entiteter (OAuth2, OpenID Connect, identitetsfederation). Det är den algoritm som föredras av de flesta publika identitetsleverantörer.
• ECDSA (ES256, ES384): asymmetrisk signatur på elliptiska kurvor. Samma logik som RSA (privat nyckel för att signera, publik nyckel för att verifiera) men med mycket mer kompakta nycklar och signaturer för motsvarande säkerhetsnivå. Allt vanligare i moderna arkitekturer.

Så tillhandahåller du nyckeln

Den förväntade nyckelns format beror på algoritmen som deklareras i JWT:ns header:

• HS256, HS384, HS512: nyckeln är en hemlig sträng. Det är den delade hemligheten med utfärdaren, ofta lagrad i en miljövariabel som JWT_SECRET. Ingen särskild formatering, bara det råa värdet.
• RS256, RS384, RS512: nyckeln är en RSA-publik nyckel i PEM-format, som börjar med -----BEGIN PUBLIC KEY----- och slutar med -----END PUBLIC KEY-----. Behåll radbrytningarna som de är, annars vägrar OpenSSL att parsa den.
• ES256, ES384: nyckeln är en ECDSA-publik nyckel i PEM-format, på motsvarande kurva (P-256 för ES256, P-384 för ES384).

Exempel på förväntad RSA-publik nyckel

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxe...
...vQIDAQAB
-----END PUBLIC KEY-----

Hur fungerar verifieringen?

Vår server reproducerar exakt den operation som utfärdaren har gjort:

1. Den separerar JWT:n i header, payload och signatur.
2. Den konkatenerar base64url(header) + "." + base64url(payload).
3. För HMAC räknar den ut en HMAC-SHA-256/384/512 med din hemliga nyckel och jämför sedan med den mottagna signaturen via hash_equals (jämförelse på konstant tid för att undvika tids- attacker).
4. För RSA anropar den openssl_verify med din publika nyckel i PEM-format.

Användningsfall

• API-autentiseringsdebug: du får en 401, kontrollera om din token är korrekt signerad med den förväntade nyckeln.
• Validering av en token från en leverantör: en partner (Auth0, Keycloak, Cognito, Okta) skickar JWT:er signerade i RS256; du vill bekräfta att de verkligen kommer från dem med deras publika nyckel.
• Säkerhetsgranskning: verifiera att en tredjepartstjänst signerar sina tokens korrekt med en robust algoritm, och inte i HS256 med en svag hemlighet.
• Manuella tester: verifiera att en JWT genererad av din kod klarar verifieringen med den tillhandahållna publika nyckeln.
• Snabb verifiering av en mottagen token: under integration av ett SSO eller ett partner-API, verifiera på några sekunder att signatur-nyckel-kedjan fungerar innan man skriver en enda kodrad.

Så använder du verktyget

1. Klistra in hela JWT:n (de tre delarna separerade med punkter).
2. Ange nyckeln anpassad till headerns algoritm:
   • För HS256, HS384 eller HS512 är nyckeln den hemliga sträng som delas med utfärdaren. Det är en fri sträng, ofta lagrad i en miljövariabel som JWT_SECRET.
   • För RS256, RS384 eller RS512 är nyckeln den publika nyckeln i PEM-format, som börjar med -----BEGIN PUBLIC KEY----- och slutar med -----END PUBLIC KEY-----.
3. Starta verifieringen. Verktyget visar statusen (giltig eller ogiltig) och den avkodade payloaden.

Vanliga fallgropar att undvika

• Algoritmen "none": specifikationen tillåter alg: none, vilket betyder "ingen signatur". En klassisk sårbarhet består i att tillverka en token med den headern i hopp om att servern ska acceptera den. Vårt verktyg avvisar systematiskt tokens med alg: none.
• Förväxling HMAC vs RSA (algorithm confusion): en angripare ändrar algoritmen RS256 till HS256 och signerar payloaden med den RSA-publika nyckel som används som HMAC-hemlighet. Om servern inte kontrollerar algoritmen accepterar den tokenen. Lås alltid den förväntade algoritmen på serversidan.
• HMAC-hemligheter hårdkodade: en hemlighet committad i ett Git-repo gör all tillit till tokens ogiltig. Lagra hemligheter i miljövariabler eller en applikationskassakåp.
• Publik nyckel vs privat nyckel: för att verifiera en JWT signerad i RSA eller ECDSA, tillhandahåller man den publika nyckeln, aldrig den privata. Den privata tjänar bara till att signera och får aldrig lämna utfärdaren.
• Ignorerad utgång: en giltig signatur på en utgången token får aldrig accepteras. Tänk på att verifiera exp och nbf.
• Okontrollerad audience: en token avsedd för API A ska inte accepteras av API B. Verifiera claimet aud.

Tidsmässiga claims: exp och nbf

Utöver signaturen måste en giltig JWT också respektera sina tidsmässiga begränsningar:

• exp (expiration): tokenen är inte längre giltig efter detta datum.
• nbf (not before): tokenen är ännu inte giltig före detta datum.

Vårt verktyg signalerar uttryckligen när en token är utgången eller ännu inte giltig, även om dess signatur är korrekt. Det är viktigt: en giltig signatur på en utgången token får aldrig accepteras i produktion.

Skillnad mot vår JWT-avkodare

Vår JWT-avkodare nöjer sig med att avkoda header- och payload-delarna för att göra dem läsbara. Den utför ingen verifiering av signatur och kräver ingen nyckel. Använd den för att snabbt inspektera innehållet i en token. Använd JWT-verifier (den här sidan) så snart du behöver bevisa att en token är äkta. För att tillverka en signerad JWT i testsyfte, använd vår JWT-byggare.

Vanliga frågor

Exempelförfrågan

curl -X POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"...","key":"..."}'

Indatasschema

Slutpunkter

• GET https://cdrn.fr/api/v1/tools - listar alla tillgängliga verktyg
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - hämtar schemat för detta verktyg
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - kör detta verktyg med en JSON-payload