Kontrolli JSON Web Token (JWT) allkirja

Miks kontrollida JWT allkirja?

JSON-i veebimärk (JWT) on jagatud kolmeks osaks, mis on eraldatud punktidega. header.payload.signature. JWT dekodeerimine on lihtsalt kahe esimese lugemise küsimus osad (mis on Base64URL). Igaüks saab seda teha ja igaüks saabteha JWT teie valitud kasuliku koormaga. JWT teeb usaldusväärseks ainult see allkiri: ilma kontrollimiseta tähendab JWT vastuvõtmine oma koju lubamist igaühe, kes teeskleb kedagi, ilma isikut tõendavat dokumenti küsimata.

See tööriist kinnitab võtmest JWT allkirja. Ta ei ole rahul dekodeerida: see arvutab uuesti allkirja päisest, kasulikust koormusest ja teie võtmest ning seejärel võrdleb seda märgi allkirjaga. Kui need kaks ühtivad, on märk autentne. Muidu oli see võltsitud, muudetud või mõne muu võtmega allkirjastatud.

Kontrollimine on mis tahes arhitektuuri nurgakivi, mis kasutab JWT-sid autentimine või autoriseerimine: ilma kehtiva allkirjata võib kasulik koormus valetada. Ründajal, kes muudab "role":"user" väärtuseks "role":"admin", pole raskusi, kui server kontrollis ainult märgi vormingut, mitte selle allkirja.

Levinud algoritmid

JWT spetsifikatsioon (RFC 7518, JSON Web Algorithms) määratleb mitu algoritmide perekonda. Siin on tootmises enim kasutatud:

• HMAC (HS256, HS384, HS512): sümmeetriline signatuur, mis põhineb HMAC-SHA-l. The Allkirjastamiseks ja kinnitamiseks kasutatakse sama salajast võtit. Lihtne seadistada, tõhus, kuid kõik osapooled, kes on suutelised tokenit kontrollima, on võimelised seda ka välja andma. Kohandatud stsenaariumidele, kus väljastaja ja tõendaja on sama meeskond või osakond.
• RSA (RS256, RS384, RS512): asümmeetriline signatuur. Privaatvõti märk, avalik võti kinnitab. Ideaalne, kui saatja ja Kinnitajad on eraldi üksused (OAuth2, OpenID Connect, Identity Federation). See on algoritm, mida eelistavad enamik avaliku identiteedi pakkujaid.
• ECDSA (ES256, ES384): asümmeetriline signatuur elliptilistel kõveratel. Sama loogika nagu RSA (privaatvõti allkirjastamiseks, avalik võti kinnitamiseks), kuid võtmetega ja kompaktsemad allkirjad samaväärse turvalisuse taseme saavutamiseks. Üha laiemalt levinud aastal kaasaegsed arhitektuurid.

Kuidas anda võti

Eeldatava võtme vorming sõltub JWT päises deklareeritud algoritmist:

• HS256, HS384, HS512: võti on salajane (string). See on emitendiga jagatud saladus, mida sageli salvestatakse keskkonnamuutujas nagu JWT_SECRET. Ei mingit erilist vormindamist, ainult toorväärtus.
• RS256, RS384, RS512: võti on PEM-vormingus avalik RSA võti, mis algab koodiga -----BEGIN AVALIK VÕTI----- ja lõpeb -----AVALIK VÕTI LÕPP-----. Jätke reavahetused nagu on, vastasel juhul OpenSSL keeldub seda sõelumast.
• ES256, ES384: võti on ECDSA avalik võti PEM-vormingus, vastaval kõveral (ES256 puhul P-256, ES384 puhul P-384).

Oodatava RSA avaliku võtme näide

-----ALGUST AVALIK VÕTI-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...
...vQIDAQAB
-----AVALIK VÕTI LÕPP-----

Kuidas kinnitamine töötab?

Meie server taasesitab täpselt saatja tehtud toimingu:

1. See jagab JWT päiseks, kasulikuks koormuseks ja signatuuriks.
2. See ühendab base64url(header) + "." + base64url(kasulik koormus).
3. HMAC-i puhul arvutab see teie salajase võtmega HMAC-SHA-256/384/512 ja võrdleb seejärel allkiri, mis on vastu võetud hash_equals kaudu (pidev ajaline võrdlus rünnakute vältimiseks aeg).
4. RSA puhul kutsub see välja funktsiooni openssl_verify teie avaliku võtmega PEM-vormingus.

Kasutusjuhtumid

• API autentimise silumine: saate 401, kontrollige, kas teie luba on hästi allkirjastatud oodatud võtmega.
• Tarnijalt saadud loa kinnitamine: partner (Auth0, Keycloak, Cognito, Okta) saadab teile RS256-ga allkirjastatud JWT-d; soovite kinnitada, et need pärinevad tema avaliku võtmega.
• Turvaaudit: kontrollige, kas kolmanda osapoole teenus allkirjastab oma märgid õigesti tugeva algoritmiga ja mitte madala salajasusega HS256-s.
• Käsitsi testid: kontrollige, kas teie koodiga loodud JWT läbib kinnitamine antud avaliku võtmega.
• Saadud loa kiire kinnitamine: SSO või Partner API, kontrollige mõne sekundi pärast, kas allkiri/võtmeahel töötab enne et kirjutada vähimgi koodirida.

Kuidas tööriista kasutada

1. Kleebi kogu JWT (kolm punktidega eraldatud osa).
2. Märkige päise algoritmile kohandatud võti:
   • Selle HS256, HS384 või HS512 puhul on võti salajane jagatudsaatjaga. See on vaba string, mis on sageli salvestatud a keskkonnamuutuja, näiteks JWT_SECRET.
   • RS256, RS384 või RS512 puhul on võti avalik võti vormingus PEM, mis algab koodiga -----BEGIN PUBLIC KEY----- ja lõpeb -----AVALIK VÕTI LÕPP-----.
3. Käitage kontroll. Tööriist kuvab oleku (kehtiv või kehtetu) ja dekodeeritud kasuliku koormuse.

Levinud lõkse, mida vältida

• Algoritm "puudub": spetsifikatsioon lubab alg: none, mis tähendab "ei" allkiri". Klassikaline viga seisneb selle päisega märgi tegemises, lootes, et server aktsepteerib seda. Meie tööriist lükkab süstemaatiliselt tagasi märgid alg: puudub.
• HMAC vs RSA segadus (algoritmi segadus): ründaja muudab algoritmi RS256 kuni HS256 ja allkirjastab kasuliku koormuse kasutatud RSA avaliku võtmega kui HMAC saladus. Kui server algoritmi ei juhi, aktsepteerib see märgi. Alati lukustada serveri poolel oodatud algoritm.
• HMAC-saladused kõvakodeeritud: Giti hoidlas tehtud saladus renderdab kogu usaldus märkide vastu on kadunud. Salvestage saladusi keskkonnamuutujatesse või rakenduste turvaline.
• Avalik vs privaatvõti: RSA-sse või ECDSA-sse logitud JWT kinnitamiseks pakub avalikku võtit, mitte kunagi privaatset. Privaatset kasutatakse ainult allkirjastamiseks ja mitte ei tohi kunagi saatjast välja tulla.
• Aegumist eirati: kehtiv allkiri aegunud märgil ei tohiks olla mitte kunagi vastu võetud. Ärge unustage märkida exp ja nbf.
• Kontrollimata vaatajaskond: API A jaoks mõeldud luba ei tohiks aktsepteerida API B poolt. Kontrollige nõuet aud.

Ajalised väited: exp ja nbf

Lisaks allkirjale peab kehtiv JWT järgima ka oma ajalisi piiranguid:

• Aeg (aegumine): pärast seda kuupäeva ei kehti luba enam.
• nbf (mitte varem): märk ei kehti enne seda kuupäeva.

Meie tööriist annab selgesõnaliselt märku, kui luba on aegunud või pole veel kehtivisegi siis, kui tema allkiri on õige. See on oluline: kehtiv allkiri a Aegunud märki ei tohiks kunagi tootmises aktsepteerida.

Erinevused meie JWT dekoodriga

Meie JWT-dekooder dekodeerib lihtsalt päise ja kasulik koormus, et muuta need loetavaks. See ei teosta allkirja kinnitamist ja ära küsi võtit. Kasutage seda žetooni sisu kiireks kontrollimiseks. Kasutage JWT kinnitaja (see leht) alati, kui peate tõestama, et luba on autentne. Testimiseks allkirjastatud JWT loomiseks kasutage meie JWT ehitaja.

Korduma kippuvad küsimused

Päringunäide

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

Sisendskeem

Lõpp-punktid

• GET https://cdrn.fr/api/v1/tools - loetleb kõik saadaolevad tööriistad
• GET https://cdrn.fr/api/v1/tools/jwt-verifier - toob selle tööriista skeemi
• POST https://cdrn.fr/api/v1/tools/jwt-verifier/execute - täidab selle tööriista JSON-payloadiga