Afkod en JSON Web Token (JWT)

Hvad er et JWT (JSON Web Token)?

Et JSON Web Token, forkortet til JWT (udtales "jot"), er et format kompakt defineret af RFC 7519, der tillader transport af en række krav (krav) mellem to parter. JWT, eller JWT-token, er det dominerende format i dag at formidle en autentificeret identitet i en HTTP API. En JWT vises som en ASCII-streng sammensat af tre segmenter adskilt af punkter:

header.payload.signature

Hvert segment er kodet i Base64URL, en variant af Base64 uden polstring = og som erstatter + med - og / med _ så det kan flyde gennem en URL- eller HTTP-header uden yderligere escape.

Anatomi af en JWT

Et json-webtoken består af tre meget adskilte dele, der hver spiller en bestemt rolle i godkendelsesmekanismen:

1. Overskrift

Headeren er et JSON-objekt, der beskriver, hvordan tokenet er signeret. Den indeholder mindst:

• alg (algoritme): den anvendte signaturalgoritme. Typiske værdier: HS256, RS256, ES256, EdDSA.
• typ (type): typen af token, næsten altid "JWT".
• kid (nøgle-id): valgfrit, identificerer hvilken nøgle der skal bruges for at bekræfte signaturen. Praktisk i nærværelse af et roterende sæt nøgler (JWKS).

2. Nyttelast

Nyttelasten indeholder kravene, det vil sige de krav, som udstederen fremsætter om brugeren eller sessionen. RFC 7519 definerer syv standardkrav (registrerede krav):

• iss (udsteder): hvem udstedte f.eks. tokenet "https://accounts.google.com".
• sub (emne): hvem ejer tokenet, i praksis bruger-id'et.
• aud (publikum): hvem tokenet er beregnet til. Undgå et token udstedt til API A accepteres af API B.
• exp (udløbstid): Unix-tidsstempel, hvorefter tokenet er ikke længere gyldig.
• nbf (ikke før): tidsstempel, før hvilket tokenet ikke er stadig aktiv.
• iat (udstedt på): tidsstempel for tokenudstedelse.
• jti (JWT ID): unik identifikator for tokenet, der bruges til tilbagekaldelse og forebyggelse af genafspilning.

Til disse standardkrav tilføjes generelt brugerdefinerede krav, der er specifikke for applikationen (roller, omfang, lejer-id, e-mail, tilladelser...).

3. Signatur

Signaturen er et kryptografisk kondensat beregnet på base64url(header) + "." + base64url(nyttelast) ved hjælp af en nøgle. Det er hende, der beviser at ingen har ændret headeren eller nyttelasten siden udsendelsen. De mest almindelige algoritmer:

• HS256 / HS384 / HS512: HMAC-SHA symmetrisk signatur. En fælles hemmelig nøgle mellem udsteder og verifikator. Enkelt, men uegnet, når der er mere end én forbruger.
• RS256 / RS384 / RS512: asymmetrisk RSA-signatur. Senderen skriver under med sin nøgle privat, verificerer enhver forbruger med den tilsvarende offentlige nøgle. De facto standard til OAuth2 og OpenID Connect.
• ES256 / ES384 / ES512: ECDSA asymmetrisk signatur. Samme egenskaber som RS256 men med meget kortere taster og signaturer.
• EdDSA (Ed25519): moderne, hurtig og kompakt asymmetrisk signatur.

Endnu en gang: signaturen beskytter integritet, ikke fortrolighed. Den nyttelast forbliver læsbar af alle, der ejer tokenet.

Hvorfor afkode en JWT?

Operationen jwt token decode opfylder flere konkrete behov for en udvikler eller en sikkerhedsingeniør:

• Authentication Debug: din API returnerer en 401 eller 403, du vil se hvad der faktisk er i nyttelasten (sub, scope, roller, exp) i stedet for at gætte.
• Tjek krav: Bekræft, at et token indeholder kravet forventet (f.eks. tenant_id eller tilladelser) før søgning andetsteds i godkendelseskæden.
• Læs udløb: konverter tidsstempel exp til menneskelig dato for bekræfte, at et token er udløbet, eller tværtimod, at det stadig skal være gyldigt.
• Sikkerhedsrevision: sikring af, at en tredjepartstjeneste ikke lækker information følsomme i nyttelasten (e-mails, interne identifikatorer, personlige data).
• Træning og forståelse: se konkret hvad en jsonwebtoken kommer ud af en OAuth-udbyder (Google, Auth0, Keycloak, AWS Cognito) for forstå mekanikken uden at dykke ned i dokumenterne.
• Udforskning af offentlige tokens: undersøg en JWT fundet i logfiler, i en cookie eller i en aflytbar OAuth-udveksling.

Dekoder vs Verifier: den kritiske skelnen

De to operationer ligner hinanden, men de har intet at gøre med hensyn til sikkerhedsgarantier:

• Afkodning af en JWT består i at opdele strengen på . og anvende en omvendt Base64URL på de første to segmenter. Det er let at læse, inden for rækkevidde af ethvert tre-linjers script. Ingen signaturbekræftelse er ikke færdig.
• Bekræftelse af en JWT består i at genberegne signaturen fra overskriften, nyttelast og en nøgle, hvorefter resultatet sammenlignes med signaturen i tokenet. Det er som garanterer, at tokenet ikke er blevet manipuleret med.

Praktisk konklusion: afkodning er ikke værd at stole på. Så længe underskriften ikke er blevet verificeret med den korrekte nøgle, kan indholdet af nyttelasten være fuldstændig falsk. For tillidsfase, brug vores JWT Verifier.

Hvordan man bruger det

1. Få JWT'en til at inspicere, for eksempel fra en header Autorisation: Bærer , fra en sessionscookie, fra localStorage fra browseren eller fra en applikationslog.
2. Indsæt hele strengen i inputfeltet. De tre segmenter skal forblive adskilt af point.
3. Værktøjet viser straks headeren afkodet til formateret JSON, med algoritmen og typen.
4. nyttelasten afkodes og vises derefter. Du ser alle påstandene der standard og brugerdefineret.
5. Værktøjet angiver også signaturoplysningerne (erklæret algoritme, længde), uden at kontrollere det.
6. For at bekræfte, at tokenet ikke er blevet manipuleret, skal du skifte til vores JWT Verifier med den forventede offentlige nøgle eller hemmelighed.

Al afkodning sker i din browser i JavaScript: dit token sendes aldrig til vores servere.

JWT og sikkerhed: faldgruber at undgå

Et par gyldne regler for korrekt brug af JWT i produktionen:

• Kontroller altid signaturen på serversiden, før du giver nogen rettigheder. Vores JWT Verifier illustrerer præcis denne operation.
• Foretrækker RS256 eller ES256 frem for HS256 til offentlige API'er. Signaturen asymmetrisk undgår at dele en hemmelighed mellem senderen og hver forbruger.
• Respekter altid exp-påstanden. En JWT uden udløb eller med udånding for langt er en tidsindstillet bombe i tilfælde af en lækage.
• Valider iss og aud på serversiden for at forhindre en legitim token udstedt til en anden tjeneste accepteres ved en fejl.
• Afvis alg: "ingen" på bekræftelsessiden. Dette er en klassisk fejl som tillader en angriber at forfalske enhver nyttelast.
• Hold levetiden kort (f.eks. 15 minutter) og par med en Opdater token længere, men kan tilbagekaldes på serversiden.

Eksempel på afkodet JWT-token

Her er en typisk JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obi IsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Når den er afkodet, er dens indhold her:

// Overskrift
{
  "alg": "HS256",
  "type": "JWT"
}

// Nyttelast
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Signatur (binær, Base64URL-kodet)
HMACSHA256(
  base64url(header) + "." + base64url(nyttelast),
  hemmelighed
)

Hvor finder man en JWT at kopiere?

I praksis kommer en JWT til dekryptere (i betydningen afkodning) oftest fra en af disse steder:

• HTTP Cookie: Åbn udviklingsværktøjerne (F12), fanen Applikation eller Lagring og derefter Cookies. Find en navngivet cookie adgangstoken, jwt, session eller lignende.
• localStorage / sessionStorage: samme panel, Lokal lagerplads. Mange SPA'er gemmer deres token der under en nøgle token eller auth.
• Autorisation overskrift: Netværk fane, vælg en API-anmodning, læs Authorization: Bearer -headeren. Kopier kun del efter Bærer .
• Serverlogfiler: en JWT vises nogle gange i logfilerne på en gateway eller en omvendt proxy (skal undgås i produktionen, men nyttig ved fejlretning).

Ofte stillede spørgsmål

Anmodningseksempel

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

Inputskema

Endpoints

• GET https://cdrn.fr/api/v1/tools - lister alle tilgængelige værktøjer
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - henter skemaet for dette værktøj
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - udfører dette værktøj med et JSON-payload