Dekodēt JSON Web Token (JWT)

Kas ir JWT (JSON Web Token)?

JSON tīmekļa marķieris, saīsināts uz JWT (izrunā "jot"), ir formāts kompakts, ko nosaka RFC 7519, kas ļauj transportēt vairākas pretenzijas (prasības) starp divām pusēm. JWT jeb JWT marķieris mūsdienās ir dominējošais formāts lai sniegtu autentificētu identitāti HTTP API. JWT parādās kā ASCII virkne sastāv no trīs segmentiem, kas atdalīti ar punktiem:

header.payload.signature

Katrs segments ir kodēts Base64URL — Base64 variantā bez polsterējuma. = un kas aizstāj + ar - un / ar _ lai tas varētu plūst caur URL vai HTTP galveni bez papildu aizbēgšanas.

JWT anatomija

Json tīmekļa marķieris sastāv no trim ļoti atšķirīgām daļām, un katrai no tām ir noteikta loma autentifikācijas mehānismā:

1. Galvene

Galvene ir JSON objekts, kas apraksta marķiera parakstīšanas veidu. Tas satur vismaz:

• alg (algoritms): izmantotais paraksta algoritms. Tipiskās vērtības: HS256, RS256, ES256, EdDSA.
• typ (tips): marķiera veids, gandrīz vienmēr "JWT".
• bērns (atslēgas ID): neobligāts, norāda, kura atslēga ir jāizmanto lai pārbaudītu parakstu. Praktiski, ja ir rotējošs atslēgu komplekts (JWKS).

2. Kravnesība

Lietderīgā slodze satur pretenzijas, tas ir, prasības, ko izsniedz emitents par lietotāju vai sesiju. RFC 7519 definē septiņas standarta pretenzijas (reģistrētas pretenzijas):

• iss (izdevējs): kurš, piemēram, izsniedza pilnvaru "https://accounts.google.com".
• apakš (subject): kam pieder pilnvara, praksē lietotāja ID.
• audi (auditorija): kam marķieris ir paredzēts. Izvairieties no marķiera izdots API A, akceptē API B.
• exp (derīguma termiņš): Unix laikspiedols, pēc kura marķieris vairs nav derīgs.
• nbf (ne agrāk): laikspiedols, pirms kura marķieris nav joprojām ir aktīvs.
• iat (izsniegts): pilnvaras izdošanas laikspiedols.
• jti (JWT ID): unikāls marķiera identifikators, ko izmanto atsaukšana un atkārtošanas novēršana.

Šīm standarta pretenzijām parasti tiek pievienotas pielāgotas pretenzijas lietojumprogramma (lomas, tvērums, nomnieka_id, e-pasts, atļaujas...).

3. Paraksts

Paraksts ir kriptogrāfisks kondensāts, kas aprēķināts base64url(header) + "." + base64url(payload), izmantojot atslēgu. Tā ir viņa, kas pierāda ka neviens nav mainījis galveni vai lietderīgo slodzi kopš pārraides. Visizplatītākie algoritmi:

• HS256/HS384/HS512: HMAC-SHA simetrisks paraksts. Koplietota slepenā atslēga starp izdevēju un verificētāju. Vienkāršs, bet nepiemērots, ja ir vairāk nekā viens patērētājs.
• RS256/RS384/RS512: asimetrisks RSA paraksts. Raidītājs parakstās ar savu atslēgu privāts, jebkurš patērētājs verificē ar atbilstošo publisko atslēgu. De facto standarts OAuth2 un OpenID Connect.
• ES256/ES384/ES512: ECDSA asimetrisks paraksts. Tās pašas īpašības kā RS256, bet ar daudz īsākiem taustiņiem un parakstiem.
• EdDSA (Ed25519): moderns, ātrs un kompakts asimetrisks paraksts.

Vēlreiz: paraksts aizsargā integritāti, nevis konfidencialitāti. The lietderīgā slodze joprojām ir lasāma ikvienam, kam pieder pilnvara.

Kāpēc atšifrēt JWT?

Darbība jwt marķiera atšifrēšana atbilst vairākām konkrētām izstrādātāja vajadzībām vai drošības inženieris:

• Autentifikācijas atkļūdošana: jūsu API atgriež 401 vai 403, ko vēlaties redzēt kas faktiski atrodas kravnesībā (apakšējā slodze, scope, lomas, exp), nevis uzminēt.
• Pārbaudīt pretenzijas: apstipriniet, ka marķieris satur pretenziju sagaidāms (piem., tenant_id vai atļaujas) pirms meklēšanas citur autorizācijas ķēdē.
• Nolasīt derīguma termiņu: konvertējiet laika zīmogu exp uz cilvēka datumu apstipriniet, ka marķiera derīguma termiņš ir beidzies, vai gluži pretēji, ka tam joprojām ir jābūt derīgam.
• Drošības audits: nodrošina, lai trešās puses pakalpojums nenopludinātu informāciju sensitīva slodze (e-pasti, iekšējie identifikatori, personas dati).
• Apmācība un izpratne: uzziniet, ko konkrēti a jsonwebtoken, ko piedāvā OAuth nodrošinātājs (Google, Auth0, Keycloak, AWS Cognito) izprast mehāniku, neiedziļinoties dokumentos.
• Publisko marķieru izpēte: pārbaudiet žurnālos atrasto JWT sīkfailā vai pārtveramā OAuth apmaiņā.

Dekodētājs pret verificētāju: kritiskā atšķirība

Abas operācijas šķiet līdzīgas, taču tām nav nekāda sakara ar drošības garantijām:

• JWT atkodēšana ietver virknes sadalīšanu . un lietot apgriezto Base64URL pirmajiem diviem segmentiem. Tas ir vienkārši lasāms, sasniedzams jebkura trīsrindu skripta. Nav paraksta verifikācijas nav izdarīts.
• JWT pārbaude sastāv no paraksta pārrēķināšanas no galvenes, lietderīgo slodzi un atslēgu, pēc tam salīdzinot rezultātu ar pilnvarā esošo parakstu. Tas ir kas garantē, ka marķieris nav bojāts.

Praktisks secinājums: atkodēšanai nav vērts uzticēties. Kamēr paraksts nav pārbaudīts ar pareizo atslēgu, lietderīgās slodzes saturs var būt pilnīgi viltus. Par uzticamības fāzē, izmantojiet mūsu JWT verificētāju.

Kā to lietot

1. Nodrošiniet JWT pārbaudi, piemēram, no galvenes Autorizācija: nesējs , no sesijas sīkfaila, no localStorage no pārlūkprogrammas vai lietojumprogrammu žurnāla.
2. Ielīmējiet pilnu virkni ievades laukā. Trīs segmenti jāpaliek atdalītiem ar punktus.
3. Rīks nekavējoties parāda galveni, kas ir dekodēta formatētā JSON formātā ar algoritmu un veidu.
4. Pēc tam lietderīgā slodze tiek atšifrēta un parādīta. Tur jūs redzat visas pretenzijas standarta un pielāgota.
5. Rīks norāda arī paraksta informāciju (deklarētais algoritms, garums), nepārbaudot to.
6. Lai apstiprinātu, ka marķieris nav bojāts, pārejiet uz mūsu JWT verificētājs ar paredzēto publisko atslēgu vai noslēpumu.

Visa dekodēšana tiek veikta jūsu pārlūkprogrammā JavaScript — jūsu pilnvara nekad netiek nosūtīta uz mūsu serveriem.

JWT un drošība: kļūmes, no kurām jāizvairās

Daži zelta likumi, kā pareizi izmantot JWT ražošanā:

• Pirms tiesību piešķiršanas vienmēr pārbaudiet servera puses parakstu. Mūsu JWT verificētājs parāda tieši šo darbību.
• Publiskām API dodiet priekšroku RS256 vai ES256, nevis HS256. Paraksts asimetriska izvairās dalīties ar noslēpumu starp raidītāju un katru patērētāju.
• Vienmēr ievērojiet exp pretenziju. JWT bez derīguma termiņa beigām vai ar pārāk tālu izelpojot ir bumba ar laika degli noplūdes gadījumā.
• Apstipriniet iss un aud servera pusē, lai novērstu citam pakalpojumam izsniegta likumīga pilnvara tiek pieņemta kļūdas dēļ.
• Verifikācijas pusē norādiet alg: "none". Tas ir klasisks trūkums kas ļauj uzbrucējam viltot jebkuru derīgo slodzi.
• Saglabājiet īsu kalpošanas laiku (piemēram, 15 minūtes) un savienojiet pārī ar a atsvaidzināt pilnvaru ilgāk, taču servera pusē to var atsaukt.

Atšifrēta JWT marķiera piemērs

Šeit ir tipisks JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obi IsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Pēc atkodēšanas šeit ir tā saturs:

// Galvene
{
  "alg": "HS256",
  "tips": "JWT"
}

// Krava
{
  "sub": "123",
  "vārds": "Jānis",
  "iat": 1516239022
}

// Paraksts (binārs, Base64URL kodēts)
HMACSHA256(
  base64url(header) + "." + base64url (lietderīgā slodze),
  noslēpums
)

Kur atrast JWT, ko kopēt?

Praksē JWT atšifrēšanai (dekodēšanas nozīmē) visbiežāk nāk no kāda no šiem atrašanās vietas:

• HTTP sīkfails: atveriet izstrādes rīku (F12) cilni Lietojumprogramma vai Krātuve, pēc tam Sīkfaili. Atrodiet nosauktu cepumu piekļuves_tokens, jwt, sesija vai līdzīgi.
• localStorage / sessionStorage: tas pats panelis, Sadaļā Vietējā krātuve. Daudzi SPA tur savu žetonu glabā zem atslēgas token vai auth.
• Autorizācijas galvene: cilnē Tīkls atlasiet vienu API pieprasījumu, izlasiet Authorization: Bearer galveni. Kopējiet tikai daļa aiz Nesējs .
• Servera žurnāli: JWT dažkārt tiek parādīts vārtejas vai apgrieztais starpniekserveris (no tā jāizvairās ražošanā, taču tas ir noderīgs atkļūdošanā).

Bieži uzdotie jautājumi

Pieprasījuma piemērs

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

Ievades shēma

Endpoint

• GET https://cdrn.fr/api/v1/tools - uzskaita visus pieejamos rīkus
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - iegūst šī rīka shēmu
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - izpilda šo rīku ar JSON payload