Preveriti podpis JSON Web Token (JWT)

Zakaj preverjati podpis JWT?

Spletni žeton JSON (JWT) je razdeljen na tri dele, ločene s pikami: header.payload.signature. Dekodiranje JWT je preprosto stvar branja prvih dveh deli (ki so Base64URL). Vsakdo lahko to naredi in vsak lahkonaredi JWT s tovorom po vaši izbiri. Tisto, zaradi česar je JWT vreden zaupanja, je samo podpis: brez preverjanja sprejemanje JWT pomeni, da v svoj dom spustite vsakogar, ki pretvarja se, da je nekdo, ne da bi zahteval identifikacijo.

To orodje preveri podpis JWT iz ključa. Ni zadovoljen z dekodiranje: ponovno izračuna podpis iz glave, tovora in vašega ključa, nato pa ga primerja s podpisom žetona. Če se ujemata, je žeton pristen. Sicer je bilo ponarejeno, spremenjen ali podpisan z drugim ključem.

Preverjanje je temelj vsake arhitekture, ki uporablja JWT za avtentikacija ali avtorizacija: brez veljavnega podpisa lahko tovor laže. Napadalec, ki spremeni "role":"user" v "role":"admin", ne bi imel težave pri tem, če je strežnik preveril samo obliko žetona in ne njegovega podpisa.

Skupni algoritmi

Specifikacija JWT (RFC 7518, spletni algoritmi JSON) definira več družin algoritmov. Tukaj je najbolj uporabljeni v proizvodnji:

• HMAC (HS256, HS384, HS512): simetrični podpis, ki temelji na HMAC-SHA. The Za podpisovanje in preverjanje se uporablja isti tajni ključ. Enostavna nastavitev, učinkovito, toda vsaka stranka, ki je sposobna preveriti žeton, ga je sposobna tudi izdati. Prilagojeno na scenarije, kjer sta izdajatelj in preveritelj ista ekipa ali oddelek.
• RSA (RS256, RS384, RS512): asimetrični podpis. Zasebni ključ znak, javni ključ preveri. Idealno, ko oddajnik in Preverjevalci so ločene entitete (OAuth2, OpenID Connect, Identity Federation). je algoritem, ki ga podpira večina ponudnikov javne identitete.
• ECDSA (ES256, ES384): asimetrični podpis na eliptičnih krivuljah. Ista logika kot RSA (zasebni ključ za podpis, javni ključ za preverjanje), vendar s ključi in bolj kompaktni podpisi za enakovredno raven varnosti. Vse bolj razširjena v moderne arhitekture.

Kako zagotoviti ključ

Format pričakovanega ključa je odvisen od algoritma, deklariranega v glavi JWT:

• HS256, HS384, HS512: ključ je skrivni niz (niz). To je skrivnost, ki se deli z izdajateljem, pogosto shranjena v spremenljivki okolja, kot je JWT_SECRET. Brez posebnega oblikovanja, samo neobdelana vrednost.
• RS256, RS384, RS512: ključ je javni ključ RSA v formatu PEM, ki se začne z -----BEGIN PUBLIC KEY----- in konča z -----KONEC JAVNEGA KLJUČA-----. Ohranite nove vrstice takšne, kot so, sicer OpenSSL ga noče razčleniti.
• ES256, ES384: ključ je javni ključ ECDSA v formatu PEM, na ustrezni krivulji (P-256 za ES256, P-384 za ES384).

Primer pričakovanega javnega ključa RSA

-----ZAČETEK JAVNEGA KLJUČA-----
MIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----KONEC JAVNEGA KLJUČA-----

Kako poteka preverjanje?

Naš strežnik natančno reproducira operacijo, ki jo izvede oddajnik:

1. JWT ločuje na glavo, obremenitev in podpis.
2. Združuje base64url(header) + "." + base64url(tovor).
3. Za HMAC izračuna HMAC-SHA-256/384/512 z vašim tajnim ključem in ga nato primerja z podpis, prejet prek hash_equals (konstantna časovna primerjava za preprečevanje napadov čas).
4. Za RSA pokliče openssl_verify z vašim javnim ključem v formatu PEM.

Primeri uporabe

• Odpravljanje napak pri preverjanju pristnosti API-ja: prejmete 401, preverite, ali je vaš žeton dobro podpisan s pričakovanim ključem.
• Preverjanje žetona, prejetega od dobavitelja: partner (Auth0, Keycloak, Cognito, Okta) vam pošlje JWT-je, podpisane v RS256; želite potrditi, da prihajajo iz njega z njegovim javnim ključem.
• Varnostna revizija: preverite, ali storitev tretje osebe pravilno podpisuje svoje žetone z robustnim algoritmom in ne v HS256 z nizko tajnostjo.
• Ročni testi: preverite, ali JWT, ki ga ustvari vaša koda, prestane preverjanje s posredovanim javnim ključem.
• Hitro preverjanje prejetega žetona: med integracijo SSO ali Partner API, preverite čez nekaj sekund, ali podpis/veriga ključev deluje prej da napišete najmanjšo vrstico kode.

Kako uporabljati orodje

1. Prilepite celoten JWT (trije deli, ločeni s pikami).
2. Navedite ključ, prilagojen algoritmu glave:
   • Za HS256, HS384 ali HS512 je ključ skrivni niz deliz oddajnikom. Je brezplačen niz, pogosto shranjen v a spremenljivka okolja, kot je JWT_SECRET.
   • Za RS256, RS384 ali RS512 je ključ javni ključ v obliki PEM, ki se začne z -----BEGIN PUBLIC KEY----- in konča z -----KONEC JAVNEGA KLJUČA-----.
3. Izvedite preverjanje. Orodje prikaže status (veljavno ali neveljavno) in dekodirano obremenitev.

Pogoste pasti, ki se jim je treba izogniti

• Algoritem "none": specifikacija dovoljuje alg: none, kar pomeni "ne podpis". Klasična napaka je izdelava žetona s to glavo v upanju, da bo strežnik to sprejme. Naše orodje sistematično zavrača žetone z alg: brez.
• Zmeda HMAC proti RSA (zmeda algoritma): napadalec spremeni algoritem RS256 v HS256 in podpiše tovor z uporabljenim javnim ključem RSA kot skrivnost HMAC. Če strežnik ne nadzoruje algoritma, sprejme žeton. Vedno zakleni pričakovani algoritem na strani strežnika.
• Trdno kodirane skrivnosti HMAC: upodobitev skrivnosti, odobrene v repozitoriju Git vse zaupanje v žetone je izginilo. Shranjevanje skrivnosti v spremenljivke okolja oz varna aplikacija.
• Javni ključ proti zasebnemu ključu: za preverjanje JWT, podpisanega v RSA ali ECDSA, ponuja javni ključ, nikoli zasebnega. Zasebni se uporablja samo za podpisovanje in ne nikoli ne sme izstopiti iz oddajnika.
• Potek prezrt: veljaven podpis na potečenem žetonu ne bi smel nikoli ne bo sprejet. Ne pozabite preveriti exp in nbf.
• Nenadzorovano občinstvo: žeton, namenjen za API A, ne bi smel biti sprejet API B. Preverite zahtevek aud.

Časovni zahtevki: exp in nbf

Poleg podpisa mora veljaven JWT upoštevati tudi svoje časovne omejitve:

• exp (iztek): žeton po tem datumu ni več veljaven.
• nbf (ne prej): žeton pred tem datumom še ni veljaven.

Naše orodje izrecno sporoči, ko je žeton potekel ali še ni veljavni, tudi če je njegov podpis pravilen. To je pomembno: veljaven podpis na a Žetona, ki je potekel, ne smete nikoli sprejeti v produkciji.

Razlika z našim dekoderjem JWT

Naš dekoder JWT samo dekodira glavo in obremenitev, da jih naredite berljive. Ne izvaja nobenega preverjanja podpisa in ne zahtevaj ključa. Uporabite ga za hiter pregled vsebine žetona. Uporabite Preverjevalnik JWT (ta stran) vsakič, ko morate dokazati, da je žeton verodostojno. Če želite narediti podpisan JWT za testiranje, uporabite naš Graditelj JWT.

Pogosta vprašanja

Primer zahteve

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

Vhodna shema

Končne točke

• GET https://cdrn.fr/api/v1/tools - izpiše vsa razpoložljiva orodja
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - pridobi shemo tega orodja
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - izvede to orodje s JSON payloadom