Patikrinti JSON Web Token (JWT) parašą

Kodėl verta patikrinti JWT parašą?

JSON žiniatinklio prieigos raktas (JWT) suskirstytas į tris dalis, atskirtas taškais: header.payload.signature. JWT dekodavimas yra tiesiog pirmųjų dviejų skaitymo reikalas dalys (kurios yra Base64URL). Tai gali padaryti bet kas ir galipadaryti JWT su jūsų pasirinktu naudingu kroviniu. JWT patikimas yra tik tai parašas: be patikrinimo, JWT priėmimas prilygsta įleidimui į savo namus bet ką, kas apsimeta kažkuo, neprašydamas atpažinti.

Šis įrankis patvirtina JWT parašą iš rakto. Jis nepatenkintas dekoduoti: jis perskaičiuoja parašą iš antraštės, naudingos apkrovos ir jūsų rakto, tada palygina jį su žetono parašu. Jei du sutampa, ženklas yra autentiškas. Priešingu atveju jis buvo suklastotas, modifikuotas arba pasirašytas kitu raktu.

Patvirtinimas yra bet kurios architektūros, kuriai naudojami JWT, kertinis akmuo autentifikavimas arba įgaliojimas: be galiojančio parašo naudingoji apkrova gali gulėti. Užpuolikas, pakeitęs "role":"user" į "role":"admin", neturės sunku tai padaryti, jei serveris patikrino tik prieigos rakto formatą, o ne jo parašą.

Įprasti algoritmai

JWT specifikacija (RFC 7518, JSON Web Algorithms) apibrėžia kelias algoritmų šeimas. Čia yra gamyboje dažniausiai naudojami:

• HMAC (HS256, HS384, HS512): simetriškas parašas, pagrįstas HMAC-SHA. The Pasirašymui ir patvirtinimui naudojamas tas pats slaptasis raktas. Paprasta nustatyti, efektyvus, tačiau bet kuri šalis, galinti patikrinti prieigos raktą, taip pat gali jį išduoti. Pritaikytas scenarijus, kai išdavėjas ir tikrintojas yra ta pati komanda arba skyrius.
• RSA (RS256, RS384, RS512): asimetrinis parašas. Privatus raktas ženklas, viešasis raktas patvirtina. Idealu, kai siųstuvas ir Tikrintojai yra atskiri subjektai (OAuth2, OpenID Connect, Identity Federation). tai algoritmas, kurį mėgsta dauguma viešųjų tapatybės teikėjų.
• ECDSA (ES256, ES384): asimetrinis parašas elipsinėse kreivėse. Ta pati logika kaip RSA (privatus raktas pasirašyti, viešasis raktas patvirtinti), bet su raktais ir kompaktiškesni parašai, užtikrinantys lygiavertį saugumo lygį. Vis labiau plinta modernios architektūros.

Kaip pateikti raktą

Tikėtino rakto formatas priklauso nuo JWT antraštėje nurodyto algoritmo:

• HS256, HS384, HS512: raktas yra slapta eilutė (eilutė). Tai paslaptis, kuria dalijamasi su emitentu, dažnai saugoma tokiame aplinkos kintamajame kaip JWT_SECRET. Jokio specialaus formatavimo, tik neapdorota vertė.
• RS256, RS384, RS512: raktas yra RSA viešasis raktas PEM formatu, kuris prasideda -----PRADĖJIMAS VIEŠAS RAKTAS----- ir baigiasi -----PABAIGA VIEŠAS RAKTAS-----. Laikykite naujas eilutes kaip yra, kitaip OpenSSL atsisako jį analizuoti.
• ES256, ES384: raktas yra ECDSA viešasis raktas PEM formatu, atitinkamoje kreivėje (P-256 ES256, P-384 ES384).

Numatomo RSA viešojo rakto pavyzdys

-----PRADĖKITE VIEŠŲJŲ RAKTŲ-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----PABAIGA VIEŠAS RAKTAS-----

Kaip veikia patvirtinimas?

Mūsų serveris tiksliai atkuria siųstuvo atliktą operaciją:

1. JWT atskiria į antraštę, naudingą apkrovą ir parašą.
2. Jis sujungia base64url(header) + "." + base64url(naudingoji apkrova).
3. Naudojant HMAC, jis apskaičiuoja HMAC-SHA-256/384/512 naudodamas jūsų slaptą raktą, tada palygina su parašas, gautas per hash_equals (nuolatinis laiko palyginimas, siekiant išvengti atakų laikas).
4. RSA iškviečia openssl_verify su jūsų viešuoju raktu PEM formatu.

Naudojimo atvejai

• API autentifikavimo derinimas: gaunate 401, patikrinkite, ar jūsų prieigos raktas gerai pasirašytas su laukiamu raktu.
• Iš tiekėjo gauto prieigos rakto patvirtinimas: partnerio (Auth0, Keycloak, Cognito, Okta) siunčia jums JWT, pasirašytus RS256; norite patvirtinti, kad jie kilę iš su jo viešuoju raktu.
• Saugos auditas: patikrinkite, ar trečiosios šalies paslauga tinkamai pasirašo savo prieigos raktus su patikimu algoritmu, o ne HS256 su mažu slaptumu.
• Rankiniai testai: patikrinkite, ar jūsų kodo sugeneruotas JWT atitinka patvirtinimas pateiktu viešuoju raktu.
• Greitas gauto prieigos rakto patvirtinimas: integruojant SSO arba Partnerio API, po kelių sekundžių patikrinkite, ar parašas / raktų grandinė veikia anksčiau kad parašytų menkiausią kodo eilutę.

Kaip naudotis įrankiu

1. Įklijuokite visą JWT (trys dalys, atskirtos taškais).
2. Nurodykite raktą, pritaikytą antraštės algoritmui:
   • Jei naudojate HS256, HS384 arba HS512, raktas yra slapta eilutė bendrinamassu siųstuvu. Tai nemokama eilutė, dažnai saugoma a aplinkos kintamasis, pvz., JWT_SECRET.
   • Jei naudojate RS256, RS384 arba RS512, raktas yra viešasis raktas tokiu formatu PEM, kuris prasideda -----BEGIN PUBLIC KEY----- ir baigiasi -------------------.
3. Paleiskite patikrinimą. Įrankis rodo būseną (galioja arba negalioja) ir dekoduotą naudingą apkrovą.

Dažnos klaidos, kurių reikia vengti

• Algoritmas „nėra“: specifikacija leidžia alg: none, o tai reiškia „ne“ parašas“. Klasikinis trūkumas yra tokeno su šia antrašte kūrimas tikintis, kad serveris jį priima. Mūsų įrankis sistemingai atmeta žetonus su alg: nėra.
• HMAC ir RSA painiava (algoritmų painiava): užpuolikas pakeičia algoritmą RS256 į HS256 ir pasirašo naudingą krovinį naudodamas RSA viešąjį raktą kaip HMAC paslaptis. Jei serveris nevaldo algoritmo, jis priima žetoną. Visada užrakinti laukiamą algoritmą serverio pusėje.
• HMAC paslaptys užkoduotos: „Git“ saugykloje paskelbta paslaptis atvaizduojama dingo visas pasitikėjimas žetonais. Saugokite paslaptis aplinkos kintamuosiuose arba saugi programa.
• Viešasis ir privatus raktas: norėdami patvirtinti JWT, prisijungusį prie RSA arba ECDSA, mes suteikia viešąjį raktą, o ne privatų. Privatus naudojamas tik pasirašymui ir ne niekada neturi išeiti iš siųstuvo.
• Galiojimo pabaigos nepaisoma: galiojantis parašas ant pasibaigusio prieigos rakto neturėtų būti niekada nepriimti. Nepamirškite pažymėti exp ir nbf.
• Nekontroliuojama auditorija: prieigos raktas, skirtas API A, neturėtų būti priimtas pagal API B. Patikrinkite teiginį aud.

Laikini reikalavimai: exp ir nbf

Be parašo, galiojantis JWT taip pat turi laikytis savo laiko apribojimų:

• galiojimo laikas (galiojimo laikas): po šios datos prieigos raktas nebegalioja.
• nbf (ne anksčiau): prieigos raktas dar negalioja iki šios datos.

Mūsų įrankis aiškiai praneša, kai prieigos raktas baigė galioti arba dar ne galiojati, net jei jo parašas yra teisingas. Tai svarbu: galiojantis parašas ant a Pasibaigęs prieigos raktas niekada neturėtų būti priimtas gamyboje.

Skirtumas su mūsų JWT dekoderiu

Mūsų JWT dekoderis tiesiog iškoduoja antraštę ir naudingą apkrovą, kad jie būtų įskaitomi. Ji neatlieka jokio parašo patvirtinimo ir neklausk rakto. Naudokite jį norėdami greitai patikrinti žetono turinį. Naudokite JWT patvirtinimo priemonė (šiame puslapyje), kai reikia įrodyti, kad prieigos raktas yra autentiškas. Norėdami išbandyti pasirašytą JWT, naudokite mūsų JWT kūrėjas.

Dažnai užduodami klausimai

Užklausos pavyzdys

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

Įvesties schema

Galiniai taškai

• GET https://cdrn.fr/api/v1/tools - išvardija visus galimus įrankius
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - gauna šio įrankio schemą
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - vykdo šį įrankį su JSON payload