Verificer signaturen af en JSON Web Token (JWT)

Hvorfor bekræfte signaturen på en JWT?

Et JSON Web Token (JWT) er opdelt i tre dele adskilt af perioder: header.payload.signature. Afkodning af en JWT er simpelthen et spørgsmål om at læse de to første dele (som er Base64URL). Alle kan gøre det, og alle kanlave det en JWT med den nyttelast efter eget valg. Det, der gør en JWT troværdig, er kun signatur: uden bekræftelse svarer accept af en JWT til at lukke nogen ind i dit hjem, som udgiver sig for at være nogen, uden at bede om identifikation.

Dette værktøj verificerer signaturen af en JWT fra en nøgle. Han er ikke tilfreds med afkode: den genberegner signaturen fra headeren, nyttelasten og din nøgle og sammenligner den derefter med tokens underskrift. Hvis de to matcher, er tokenet autentisk. Ellers var det smedet, ændret eller signeret med en anden nøgle.

Verifikation er hjørnestenen i enhver arkitektur, der bruger JWT'er til godkendelse eller autorisation: uden en gyldig signatur kan nyttelasten ligge. En angriber, der ændrer "role":"bruger" til "role":"admin" ville ikke have nogen vanskeligheder ved at gøre det, hvis serveren kun kontrollerede tokenets format og ikke dets signatur.

Almindelige algoritmer

JWT-specifikationen (RFC 7518, JSON Web Algorithms) definerer flere familier af algoritmer. Her er de mest brugte i produktionen:

• HMAC (HS256, HS384, HS512): symmetrisk signatur baseret på HMAC-SHA. Den samme hemmelige nøgle bruges til signering og bekræftelse. Enkel at sætte op, effektivt, men enhver part, der er i stand til at verificere tokenet, er også i stand til at udstede det. Tilpasset til scenarier, hvor udstederen og verifikatoren er det samme team eller afdeling.
• RSA (RS256, RS384, RS512): asymmetrisk signatur. Denprivate nøgle tegn, bekræfter den offentlige nøgle. Ideel når senderen og Verifikatorer er separate enheder (OAuth2, OpenID Connect, Identity Federation). Det er den algoritme, der foretrækkes af de fleste offentlige identitetsudbydere.
• ECDSA (ES256, ES384): asymmetrisk signatur på elliptiske kurver. Samme logik som RSA (privat nøgle til at underskrive, offentlig nøgle til at verificere), men med nøgler og mere kompakte signaturer for et tilsvarende sikkerhedsniveau. Stadig mere udbredt i moderne arkitektur.

Sådan giver du nøglen

Formatet på den forventede nøgle afhænger af den algoritme, der er erklæret i JWT-headeren:

• HS256, HS384, HS512: nøglen er en hemmelig streng (streng). Dette er hemmeligheden, der deles med udstederen, ofte gemt i en miljøvariabel som JWT_SECRET. Ingen speciel formatering, kun den rå værdi.
• RS256, RS384, RS512: Nøglen er en offentlig RSA-nøgle i PEM-format, som starter med -----BEGIN PUBLIC KEY----- og slutter med -----SLUT OFFENTLIG NØGLE-----. Behold newlines som de er, ellers OpenSSL nægter at parse det.
• ES256, ES384: Nøglen er en offentlig ECDSA-nøgle i PEM-format, på den tilsvarende kurve (P-256 for ES256, P-384 for ES384).

Eksempel på forventet offentlig RSA-nøgle

-----BEGIN OFFENTLIG NØGLE-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----SLUT OFFENTLIG NØGLE-----

Hvordan fungerer verifikation?

Vores server gengiver nøjagtigt den operation, der udføres af senderen:

1. Den adskiller JWT i header, nyttelast og signatur.
2. Den sammenkæder base64url(header) + "." + base64url(nyttelast).
3. For HMAC beregner den en HMAC-SHA-256/384/512 med din hemmelige nøgle og sammenligner derefter med signatur modtaget via hash_equals (konstant tidssammenligning for at undgå angreb tid).
4. For RSA kalder den openssl_verify med din offentlige nøgle i PEM-format.

Brug cases

• API-godkendelsesfejl: du modtager en 401, tjek om dit token er velsignet med den forventede nøgle.
• Validering af et token modtaget fra en leverandør: en partner (Auth0, Keycloak, Cognito, Okta) sender dig JWT'er signeret i RS256; du vil bekræfte, at de kommer fra af ham med hans offentlige nøgle.
• Sikkerhedsrevision: Bekræft, at en tredjepartstjeneste signerer sine tokens korrekt med en robust algoritme, og ikke i HS256 med lav hemmeligholdelse.
• Manuelle tests: Kontroller, at en JWT genereret af din kode består bekræftelse med den medfølgende offentlige nøgle.
• Hurtig verifikation af et modtaget token: under integrationen af en SSO eller en Partner API, tjek om et par sekunder, at signaturen/nøglekæden virker før for at skrive den mindste kodelinje.

Sådan bruger du værktøjet

1. Indsæt hele JWT (de tre dele adskilt af prikker).
2. Angiv nøglen, der er tilpasset overskriftsalgoritmen:
   • For HS256, HS384 eller HS512 er nøglen den hemmelige streng deltmed senderen. Det er en gratis streng, ofte gemt i en miljøvariabel som JWT_SECRET.
   • For RS256, RS384 eller RS512 er nøglen den offentlige nøgle i formatet PEM, som starter med -----BEGIN PUBLIC KEY----- og slutter med -----SLUT OFFENTLIG NØGLE-----.
3. Kør kontrollen. Værktøjet viser status (gyldig eller ugyldig) og den afkodede nyttelast.

Almindelige faldgruber at undgå

• Algoritme "ingen": Specifikationen tillader alg: ingen, hvilket betyder "nej underskrift". En klassisk fejl består i at lave et token med denne header i håb om, at serveren accepterer det. Vores værktøj afviser systematisk tokens med alg: ingen.
• HMAC vs RSA-forvirring (algoritmeforvirring): en angriber ændrer algoritmen RS256 til HS256 og signerer nyttelasten med den anvendte offentlige RSA-nøgle som HMAC-hemmelighed. Hvis serveren ikke styrer algoritmen, accepterer den tokenet. Altid lås den forventede algoritme på serversiden.
• HMAC-hemmeligheder hårdkodet: en hemmelighed begået i et Git-lager gengives al tillid til tokens er væk. Gem hemmeligheder i miljøvariabler eller en applikationssikker.
• Offentlig nøgle vs privat nøgle: For at bekræfte en JWT, der er logget på RSA eller ECDSA, giver den offentlige nøgle, aldrig den private. Den private bruges kun til underskrift og gør det ikke må aldrig komme ud af senderen.
• Udløb ignoreret: en gyldig signatur på et udløbet token bør ikke aldrig blive accepteret. Husk at tjekke exp og nbf.
• Ukontrolleret publikum: Et token beregnet til API A bør ikke accepteres af API B. Tjek kravet aud.

Tidsmæssige krav: exp og nbf

Ud over signaturen skal en gyldig JWT også respektere dens tidsmæssige begrænsninger:

• exp (udløb): tokenet er ikke længere gyldigt efter denne dato.
• nbf (ikke før): tokenet er endnu ikke gyldigt før denne dato.

Vores værktøj signalerer eksplicit, hvornår et token er udløbet eller endnu gyldigogså selvom hans underskrift er korrekt. Dette er vigtigt: en gyldig underskrift på en Udløbet token bør aldrig accepteres i produktionen.

Forskel med vores JWT-dekoder

Vores JWT-dekoder afkoder bare headeren og nyttelast for at gøre dem læsbare. Den udfører ikke nogen signaturbekræftelse og spørg ikke om en nøgle. Brug den til hurtigt at inspicere indholdet af et token. Brug JWT-verifikator (denne side), når du skal bevise, at et token er autentisk. For at lave en signeret JWT til test, brug vores JWT-builder.

Ofte stillede spørgsmål

Anmodningseksempel

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

Inputskema

Endpoints

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