Dekodeeri JSON Web Token (JWT)

Mis on JWT (JSON Web Token)?

JSON-i veebimärk, mille lühend on JWT (hääldatakse "jot"), on vorming RFC 7519 poolt määratletud kompaktne, mis võimaldab mitmete nõuete transportimist (nõuded) kahe poole vahel. JWT ehk JWT märk on tänapäeval domineeriv formaat autentitud identiteedi edastamiseks HTTP API-s. JWT kuvatakse ASCII stringina koosneb kolmest punktidega eraldatud segmendist:

header.payload.signature

Iga segment on kodeeritud Base64URL-sse, mis on Base64 ilma polsterduseta variant = ja mis asendab + koodiga - ja / koodiga _ et see saaks voolata läbi URL-i või HTTP päise ilma täiendava põgenemiseta.

JWT anatoomia

Jsoni veebimärk koosneb kolmest väga erinevast osast, millest igaühel on kindel roll autentimismehhanismis:

1. Päis

Päis on JSON-objekt, mis kirjeldab märgi allkirjastamist. See sisaldab vähemalt:

• alg (algoritm): kasutatav allkirjaalgoritm. Tüüpilised väärtused: HS256, RS256, ES256, EdDSA.
• tüüp (tüüp): peaaegu alati märgi tüüp "JWT".
• laps (võtme ID): valikuline, määrab, millist võtit tuleks kasutada allkirja kinnitamiseks. Praktiline pöörleva võtmekomplekti (JWKS) olemasolul.

2. Kasulik koormus

Kasulik koormus sisaldab nõudeid, st nõudeid, mida väljaandja esitab kasutaja või seansi kohta. RFC 7519 määratleb seitse standardnõuet (registreeritud väited):

• iss (väljaandja): kes näiteks loa väljastas "https://accounts.google.com".
• alam (subject): kes omab loa, praktikas kasutaja ID.
• aud (publik): kellele märk on mõeldud. Vältige märki API A jaoks välja antud, API B aktsepteerib.
• exp (aegumisaeg): Unixi ajatempel, mille järel luba ei kehti enam.
• nbf (mitte varem): ajatempel, millest enne luba pole endiselt aktiivne.
• iat (välja antud): loa väljaandmise ajatempel.
• jti (JWT ID): loa kordumatu identifikaator, mida kasutatakse tühistamine ja taasesituse vältimine.

Nendele standardnõuetele lisatakse tavaliselt konkreetsed kohandatud nõuded rakendus (rollid, ulatus, üürniku_id, e-post, load...).

3. Allkiri

Signatuur on krüptograafiline kondensaat, mis on arvutatud base64url(header) + "." + base64url(payload) kasutades võtit. Tema on see, kes tõestab et keegi pole pärast saate päist ega kasulikku koormust muutnud. Kõige tavalisemad algoritmid:

• HS256 / HS384 / HS512: HMAC-SHA sümmeetriline signatuur. Jagatud salavõti väljaandja ja tõendaja vahel. Lihtne, kuid ei sobi, kui tarbijaid on rohkem kui üks.
• RS256 / RS384 / RS512: asümmeetriline RSA-signatuur. Saatja allkirjastab oma võtmega privaatne, kontrollib iga tarbija vastava avaliku võtmega. De facto standard OAuth2 ja OpenID Connecti jaoks.
• ES256 / ES384 / ES512: ECDSA asümmeetriline signatuur. Samad omadused nagu RS256, kuid palju lühemate klahvide ja allkirjadega.
• EdDSA (Ed25519): kaasaegne, kiire ja kompaktne asümmeetriline signatuur.

Veel kord: allkiri kaitseb terviklikkust, mitte konfidentsiaalsust. The kasulik koormus jääb loetavaks kõigile, kes omavad märgi.

Miks JWT dekodeerida?

Toiming jwt token decode vastab arendaja mitmetele konkreetsetele vajadustele või ohutusinsener:

• Autentimise silumine: teie API tagastab 401 või 403, mida soovite näha mis tegelikult kasulikus koormas on (alam, ulatus, rollid, exp), mitte arvata.
• Kontrollige nõudeid: kinnitage, et luba sisaldab nõuet oodatud (nt rentant_id või load) enne otsimist mujal autoriseerimisahelas.
• Aegumisaja lugemine: teisendage ajatempel exp inimese kuupäevaks kinnitada, et luba on aegunud või vastupidi, et see peaks endiselt kehtima.
• Turvaaudit: tagab, et kolmanda osapoole teenus ei lekiks teavet tundlikud (e-kirjad, sisemised identifikaatorid, isikuandmed).
• Koolitus ja arusaamine: vaadake täpsemalt, mida a jsonwebtoken, mis tuleb välja OAuthi pakkujalt (Google, Auth0, Keycloak, AWS Cognito) mõista mehaanikat ilma dokumentidesse sukeldumata.
• Avalike žetoonide uurimine: kontrollige logidest leitud JWT-d küpsis või pealtkuulatav OAuthi vahetus.

Dekooder vs kontrollija: kriitiline erinevus

Need kaks toimingut tunduvad sarnased, kuid neil pole turvagarantiide osas midagi pistmist:

• JWT dekodeerimine seisneb stringi tükeldamises . ja rakendage kahele esimesele segmendile vastupidist Base64URL-i. See on lihtne lugemine, käeulatuses mis tahes kolmerealisest skriptist. Allkirja kinnitamine puudub pole tehtud.
• JWT kontrollimine seisneb allkirja ümberarvutamises päisest, kasulik koormus ja võti, seejärel võrrelda tulemust märgis oleva allkirjaga. See on mis garanteerib, et luba ei ole rikutud.

Praktiline järeldus: dekodeerimist ei tasu usaldada. Nii kaua kui allkiri ei ole õige võtmega kontrollitud, võib kasuliku koormuse sisu olla täiesti võlts. jaoks usaldusfaasi, kasutage meie JWT kinnitajat.

Kuidas seda kasutada

1. Laske JWT kontrollida, näiteks päisest Autoriseerimine: kandja , seansiküpsisest, alates localStorage brauserist või rakenduse logist.
2. Kleebi kogu string sisestusväljale. Kolm segmenti peavad jääma üksteisest eraldatud punktid.
3. Tööriist kuvab kohe päise, mis on dekodeeritud vormindatud JSON-i koos algoritm ja tüüp.
4. Seejärel kasulik koormus dekodeeritakse ja kuvatakse. Seal näete kõiki väiteid standardne ja kohandatud.
5. Tööriist näitab ka allkirjateavet (deklareeritud algoritm, pikkus), ilma seda kontrollimata.
6. Kinnitage, et žetoon ei ole rikutud, minge meie kontole JWT kinnitaja eeldatava avaliku võtme või saladusega.

Kogu dekodeerimine toimub teie brauseris JavaScriptis: teie luba ei saadeta kunagi meie serveritele.

JWT ja turvalisus: lõkse, mida vältida

Mõned kuldreeglid JWT õigeks kasutamiseks tootmises:

• Kontrollige alati serveripoolset allkirja enne õiguste andmist. Meie JWT kinnitaja illustreerib täpselt seda toimingut.
• Avalike API-de puhul eelistage RS256 või ES256 või HS256. Allkiri asümmeetriline väldib saladuse jagamist saatja ja iga tarbija vahel.
• Austage alati väidet exp. JWT ilma aegumiseta või koos liiga kaugele väljahingamine on lekke korral viitsütikuga pomm.
• Kinnitage serveri poolel iss ja aud, et vältida mõne teise teenuse jaoks välja antud seaduslik luba aktsepteeritakse ekslikult.
• Keelduge kinnitusküljel alg: "none". See on klassikaline viga mis võimaldab ründajal võltsida mis tahes kasulikku lasti.
• Hoidke eluiga lühike (näiteks 15 minutit) ja siduge a värskenda tokenit kauem, kuid serveri poolel on tühistatav.

Näide dekodeeritud JWT märgist

Siin on tüüpiline JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obi IsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Pärast dekodeerimist on selle sisu järgmine:

// Päis
{
  "alg": "HS256",
  "tüüp": "JWT"
}

// Kasulik koormus
{
  "sub": "123",
  "nimi": "John",
  "iat": 1516239022
}

// Allkiri (binaarne, Base64URL-i kodeering)
HMACSHA256(
  base64url(päis) + "." + base64url (kasulik koormus),
  saladus
)

Kust leida JWT, mida kopeerida?

Praktikas pärineb JWT dekrüpteerimiseks (dekodeerimise mõttes) enamasti ühest neist asukohad:

• HTTP-küpsis: avage arendustööriistade (F12) vahekaart Rakendus või Salvestusruum, seejärel Küpsised. Otsige nimega küpsist access_token, jwt, seanss või muu sarnane.
• localStorage / sessionStorage: sama paneel, Jaotis Kohalik salvestusruum. Paljud SPA-d hoiavad oma tokenit seal võtme all token või auth.
• Authorization päis: vahekaart Võrk, valige üks API päring, lugege päist Authorization: Bearer . Kopeerige ainult osa pärast kandjat .
• Serveri logid: JWT ilmub mõnikord lüüsi või lüüsi logidesse. vastupidine puhverserver (tootmises tuleb seda vältida, kuid see on kasulik silumisel).

Korduma kippuvad küsimused

Päringunäide

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

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-decoder - toob selle tööriista skeemi
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - täidab selle tööriista JSON-payloadiga