JWT Decoder
Mag-paste ng JSON Web Token para basahin ang header at payload nito, makita kung kailan ito mag-e-expire, at maunawaan ang bawat claim. Hindi kailanman umaalis sa iyong browser ang token mo.
Tumatakbo sa browser moWalang sign-upWalang ina-upload
Hindi verification ang pag-decode. Kahit sino ay kayang basahin ang header at payload ng JWT dahil base64url-encoded lang ang mga ito. Ipinapakita ng tool na ito kung ano ang sinasabi ng token; hindi nito pinapatunayang tunay ang token. Laging i-verify ang signature sa iyong server.
Header
Payload
Paliwanag ng mga claim
I-verify ang signature (opsyonal, HS256/HS384/HS512)
Sinusuri ang HMAC signature gamit ang secret na ilalagay mo, sa pamamagitan ng Web Crypto API ng iyong browser. Hindi lumalabas ang secret sa page na ito. Kailangan ng RSA/ECDSA token ang public key ng issuer kaya hindi ito vine-verify dito.
Paano gamitin ang JWT Decoder
- I-paste ang token sa box na Encoded na token. Hindi papansinin ang
Bearersa unahan mula sa Authorization header. - Agad na dine-decode ang header at payload at ipinapakita bilang naka-format na JSON.
- Basahin ang table na Paliwanag ng mga claim: kino-convert sa petsa ang
exp,iatatnbfkasama ang “mag-e-expire sa” / “nag-expire noong” na oras. - Tingnan ang status bar para sa problema sa expiry at ang mga babala para sa mapanganib na setting gaya ng
alg: none. - Kung gusto mo, ilagay ang shared secret para i-verify nang lokal ang HS256, HS384 o HS512 na signature.
Ano ang laman ng JWT?
Ang JSON Web Token (RFC 7519) ay tatlong base64url string na pinagdugtong ng tuldok: header.payload.signature. Pinapangalanan ng header ang signing algorithm (alg) at uri ng token. Hawak ng payload ang mga claim, gaya ng kung sino ang user at kailan mag-e-expire ang token. Kinakalkula ang signature mula sa unang dalawang bahagi gamit ang secret o private key.
Hindi verification ang pag-decode
Naka-encode lang, hindi naka-encrypt, ang header at payload, kaya kahit sinong may hawak ng token ay kayang basahin ang mga ito. Kaya hindi ka dapat maglagay ng password o secret sa JWT payload. Sinasabi ng pag-decode kung ano ang sinasabi ng token. Ang pag-verify ng signature, karaniwang sa iyong API server gamit ang library gaya ng jose o PyJWT, ang nagpapatunay kung sino ang nag-issue nito at na hindi ito binago. Dapat ding i-check ng server ang exp, nbf, iss at aud, at tanggihan ang mga hindi inaasahang algorithm.
Cheat sheet ng mga registered claim
| Claim | Kahulugan |
|---|---|
iss | Issuer: kung sino ang gumawa at nag-sign ng token |
sub | Subject: kadalasan ang user ID |
aud | Audience: kung para saang API ang token |
exp | Oras ng expiration, sa segundo mula sa Unix epoch |
nbf | Hindi valid bago ang oras na ito |
iat | Oras ng pag-issue |
jti | Natatanging token ID, kapaki-pakinabang para sa revocation list |
Pag-debug ng mga “token expired” na error
Kung tinatanggihan ng API ang token na mukhang bago pa, ikumpara ang exp at nbf sa orasan ng server. Karaniwan ang maliit na clock skew sa pagitan ng mga makina, kaya karamihan ng library ay nagbibigay ng 30-60 segundong palugit. I-check din na nasa segundo ang exp: madalas na bug ang millisecond na value at inilalagay nito ang expiry sa libu-libong taon sa hinaharap.
Mga madalas itanong
Ligtas bang mag-paste ng production JWT dito?
Vine-verify ba ng tool na ito ang JWT signature?
Bakit lumalabas na expired ang token ko?
exp claim kumpara sa orasan ng iyong computer. Humingi ng bagong token, o i-refresh ito gamit ang iyong refresh token. Kung mukhang mali ang mga oras, tingnan kung may clock skew o kung nakasulat sa millisecond ang exp value.Ano ang pagkakaiba ng JWT, JWS at JWE?
Bakit mapanganib ang alg na “none”?
alg: none at ang partikular na algorithm lang na inaasahan nito ang dapat tanggapin.