Vai ir droši šeit ielīmēt manu JWT?

Jā. Dekodēšana pilnībā notiek jūsu pārlūkprogrammā — marķieris nekad netiek nosūtīts nevienam serverim. Tomēr JWT ir akreditācijas dati — nekopīgojiet tos publiski (ekrānuzņēmumos, Stack Overflow ziņās utt.), jo tie var piešķirt piekļuvi jūsu kontiem.

Vai šis rīks pārbauda JWT parakstu?

Šis rīks atšifrē un parāda marķiera saturu. Paraksta pārbaudei ir nepieciešama slepenā atslēga (HMAC) vai publiskā atslēga (RSA/ECDSA), kurai jāpaliek jūsu serverī. Rīks parāda izmantoto algoritmu, bet nevar pārbaudīt bez atslēgas.

Ko nozīmē standarta JWT prasības?

iss = izdevējs, sub = subjekts (lietotāja ID), exp = derīguma termiņš (Unix laikspiedols), iat = izdots, nbf = ne agrāk, aud = auditorija, jti = JWT ID. Pielāgotās pretenzijās var būt ietverti jebkādi ar lietojumprogrammu saistīti dati.

Kāpēc kāds var atšifrēt JWT?

JWT ir kodēti, nevis šifrēti. Kravnesība ir Base64URL kodēta (nav šifrēta), tāpēc ikviens var to izlasīt. Paraksts neļauj manipulēt, nevis lasīt. Nekad neuzglabājiet sensitīvus datus (paroles, SSN) JWT derīgajās slodzēs.

Kāpēc dažiem marķieriem trūkst paraksta?

Tokens ar algu: nevienam nav paraksta. Tie ir derīgi JWT pēc specifikācijas, taču negarantē autentiskumu, un tos nevajadzētu pieņemt ražošanā.

Vai JWT ir šifrēti?

Standarta JWT derīgās slodzes ir parakstītas, bet nav šifrētas. JWE (JSON Web Encryption, RFC 7516) ir atsevišķs formāts šifrētiem marķieriem. Lielākā daļa JWT savvaļā ir JWS (tikai parakstīti).

Vai mans marķieris ir augšupielādēts serverī?

Nē. Dekodēšana notiek jūsu pārlūkprogrammā; marķieris neatstāj jūsu ierīci.

Cik ilgi parasti ir JWT?

Jebkur no dažiem simtiem līdz vairākiem tūkstošiem rakstzīmju. Garums ir atkarīgs no pretenziju skaita un lieluma, kā arī paraksta garuma (kas ir atkarīgs no algoritma).

JWT marķieris Dekodētājs

Par šo rīku

JSON tīmekļa marķieri (JWT) ir kompakts, URL drošs formāts pretenziju pārsūtīšanai starp divām pusēm, ko definē RFC 7519. JWT ir trīs base64url kodēti segmenti, kas atdalīti ar punktiem: galvene (algoritma un marķiera veids), slodze (pretenzijas) un paraksts (kriptogrāfiskais autentiskuma apliecinājums). Galvene un slodze ir JSON, base64url kodēta URL drošībai; paraksts izmanto vienu no vairākiem algoritmiem (HS256, RS256, ES256 un citi) kodētajā galvenē un lietderīgajā slodzē.

JWT dekodēšana — sadalīšana segmentos un katra bāzes 64 dekodēšana — neprasa nekādu noslēpumu. Ikviens, kam ir marķiera teksts, var lasīt tā galveni un lietderīgo slodzi. Tomēr parakstu var pārbaudīt tikai ar slepeno (HMAC) vai publisko atslēgu (asimetrisko). Dekodēšana paredzēta pārbaudei; autentiskumu pierāda pārbaude.

Šis dekodētājs sadala marķieri, base64 dekodē katru segmentu, parsē galveni un lietderīgo slodzi kā JSON un parāda rezultātu. Tas nemēģina pārbaudīt parakstu, jo tam ir nepieciešama slepenā vai publiskā atslēga, kuras dekodētājam nav. Dekodētā izvade ir tikai lasāma pārbaude — noderīga marķieru atkļūdošanai, taču tā nevar aizstāt pareizu verifikāciju lietojumprogrammas kodā.

Kāpēc atšifrēt JWT

Autentifikācijas problēmu atkļūdošana gandrīz vienmēr ietver marķieru pārbaudi. Marķieram, kas kodā izskatās derīgs, var būt nepareizas pretenzijas, neparedzēts algoritms, beidzies derīguma termiņa laikspiedols vai mērķauditorijas neatbilstība. Marķiera atkodēšana atklāj tieši to, ko emitents ir ražojis.

Palīdz arī žetonu pārbaude integrācijas darba laikā. Veidojot savienojumu ar trešās puses API vai identitātes nodrošinātāju, faktiskos pretenziju nosaukumus, formātus un struktūru vislabāk var saprast, dekodējot parauga pilnvaras, nevis paļaujoties uz dokumentāciju, kas var būt novecojusi.

Kā lietot

Ielīmējiet marķieri, iegūstiet parsēto saturu.

Ielīmējiet savu JWT: Nometiet pilnu marķieri (header.payload.signature) ievades apgabalā. Dekodētājs pieņem marķierus ar vai bez izvēles Bearer prefiksa.
Pārbaudiet galveni: Galvene parāda parakstīšanas algoritmu (alg) un marķiera veidu (typ). Izplatītākie algoritmi ir HS256, RS256 un ES256. Uzmanieties, vai nav algu: nav, kas norāda uz neparakstītu marķieri un reti ir drošs ražošanā.
Pārbaudiet lietderīgo kravu: Lietderīgā slodze satur pretenzijas: iss (izdevējs), sub (subject), aud (auditorija), exp (termiņa beigas), iat (izsniegts) un visas ar lietojumprogrammu saistītas pretenzijas. Standarta laikspiedoli ir Unix laikmeta sekundes.
Pārbaudiet atsevišķi: Dekodētājs nepārbauda parakstu. Lai pārbaudītu autentiskumu, palaidiet marķieri JWT bibliotēkā ar atbilstošo slepeno vai publisko atslēgu lietojumprogrammas kodā.

Bieži lietojami gadījumi

Atkļūdošanas kļūdas, kurām beidzies pilnvaras termiņš — Marķiera atkodēšana atklāj exp pretenziju. Salīdziniet ar pašreizējo laiku, lai pārliecinātos, vai derīguma termiņš ir faktiskais iemesls.
Trešās puses pilnvaras pretenziju struktūras izpratne — Identitātes nodrošinātāji (Auth0, Okta, Cognito) izdod marķierus ar pakalpojumu sniedzējam raksturīgiem pretenziju izkārtojumiem. Paraugu marķieru dekodēšana parāda faktisko struktūru.
Tokenu pārbaude integrācijas laikā — Integrējot SSO vai OAuth plūsmas, marķieru dekodēšana katrā darbībā palīdz pārbaudīt, vai dati ir veidoti, kā paredzēts.
Sensitīvu datu marķiera satura auditēšana — Pēc noklusējuma marķieri nav šifrēti; krava ir nolasāma. Esošo marķieru atkodēšana palīdz pārbaudīt, vai sensitīvi dati nav iekļauti nejauši.
Auditorijas un izdevēja pretenziju pārbaude — Lai aizsargātos pret marķieru sajaukšanu, nepieciešama pareiza audio un kļūdu apstrāde. Tokenu dekodēšana testēšanas laikā apstiprina, ka šie apgalvojumi ir pareizi aizpildīti.

Tehniskās detaļas

JWT formāts ir trīs segmenti, kas savienoti ar punktiem. Katrs segments ir kodēts ar base64url — vietrādim URL drošs base64 variants, kurā tiek izmantoti — un _, nevis + un /, bet dažkārt tiek izlaista polsterēšana. Lai atšifrētu, ir jāatsauc URL droši aizstāšanas gadījumi, segmenta polsterēšana un base64 dekodēšana.

Pēc dekodēšanas galvene un lietderīgā slodze ir JSON. Paraksta segments ir binārs (neapstrādāti paraksta baiti) un nav cilvēkiem lasāms; lai verifikācijas atslēga būtu noderīga.

Izplatītas pretenzijas, kas definētas RFC 7519: iss (izdevējs), sub (subjekta identifikators), aud (auditorija), exp (derīguma termiņš — Unix laikmeta sekundes), nbf (ne pirms laikspiedola), iat (izsniegts laika zīmogs), jti (unikāls pilnvaras ID). Lietojumprogrammai specifiskas pretenzijas var parādīties ar jebkuru nosaukumu.

Labākā prakse

Nekad neuzticieties nepārbaudītam JWT — Dekodēšana atklāj tikai saturu; tas nepierāda autentiskumu. Pirms uzticaties pretenzijām, vienmēr pārbaudiet parakstu ar pareizo atslēgu lietojumprogrammas kodā.
Skatīties algu: nav — Tokens ar algu: nevienam nav paraksta. Lietojumprogrammas kods, kas tos pieņem, ir neaizsargāts pret viltošanu. Verifikācijas konfigurācijā vienmēr ir nepieciešams noteikts algoritms.
Esiet piesardzīgs ar sensitīviem datiem kravnesībā — JWT derīgās slodzes ir lasāmas ikvienam, kam ir marķieris. Šifrējiet lietderīgo slodzi (izmantojiet JWE), ja tajā ir dati, kuriem jābūt slepeniem.
Pirms apstrādes apstipriniet exp — Token, kuram beidzies derīguma termiņš, ir jānoraida pat tad, ja paraksts ir derīgs. JWT bibliotēkas parasti pārbauda exp automātiski; pārbaudiet, vai jūsu bibliotēka to dara.

Bieži uzdotie jautājumi

Vai ir droši šeit ielīmēt manu JWT?: Jā. Dekodēšana pilnībā notiek jūsu pārlūkprogrammā — marķieris nekad netiek nosūtīts nevienam serverim. Tomēr JWT ir akreditācijas dati — nekopīgojiet tos publiski (ekrānuzņēmumos, Stack Overflow ziņās utt.), jo tie var piešķirt piekļuvi jūsu kontiem.
Vai šis rīks pārbauda JWT parakstu?: Šis rīks atšifrē un parāda marķiera saturu. Paraksta pārbaudei ir nepieciešama slepenā atslēga (HMAC) vai publiskā atslēga (RSA/ECDSA), kurai jāpaliek jūsu serverī. Rīks parāda izmantoto algoritmu, bet nevar pārbaudīt bez atslēgas.
Ko nozīmē standarta JWT prasības?: iss = izdevējs, sub = subjekts (lietotāja ID), exp = derīguma termiņš (Unix laikspiedols), iat = izdots, nbf = ne agrāk, aud = auditorija, jti = JWT ID. Pielāgotās pretenzijās var būt ietverti jebkādi ar lietojumprogrammu saistīti dati.
Kāpēc kāds var atšifrēt JWT?: JWT ir kodēti, nevis šifrēti. Kravnesība ir Base64URL kodēta (nav šifrēta), tāpēc ikviens var to izlasīt. Paraksts neļauj manipulēt, nevis lasīt. Nekad neuzglabājiet sensitīvus datus (paroles, SSN) JWT derīgajās slodzēs.
Kāpēc dažiem marķieriem trūkst paraksta?: Tokens ar algu: nevienam nav paraksta. Tie ir derīgi JWT pēc specifikācijas, taču negarantē autentiskumu, un tos nevajadzētu pieņemt ražošanā.
Vai JWT ir šifrēti?: Standarta JWT derīgās slodzes ir parakstītas, bet nav šifrētas. JWE (JSON Web Encryption, RFC 7516) ir atsevišķs formāts šifrētiem marķieriem. Lielākā daļa JWT savvaļā ir JWS (tikai parakstīti).
Vai mans marķieris ir augšupielādēts serverī?: Nē. Dekodēšana notiek jūsu pārlūkprogrammā; marķieris neatstāj jūsu ierīci.
Cik ilgi parasti ir JWT?: Jebkur no dažiem simtiem līdz vairākiem tūkstošiem rakstzīmju. Garums ir atkarīgs no pretenziju skaita un lieluma, kā arī paraksta garuma (kas ir atkarīgs no algoritma).

JWT marķieris Dekodētājs

Saistītie rīki

URL kodētājs / Dekodētājs

Base64 kodētājs / Dekodētājs

JSON formatētājs & Validators

XML formatētājs & Validators

Par šo rīku

Kāpēc atšifrēt JWT

Kā lietot

Bieži lietojami gadījumi

Tehniskās detaļas

Labākā prakse

Bieži uzdotie jautājumi

Related Articles

Essential Developer Tools: JSON, Base64, RegEx, and More

Hashing, Encryption, and Encoding Explained: A Developer's Security Guide

Spreadsheet & Data Conversion Guide: Excel, CSV, JSON, and More

Why Browser-Based Tools Are the Future: No Installs, No Uploads, No Risk