Utilia

JWT Decoder

I-decode ang header at payload ng JWT, basahin ang exp, iat at nbf bilang petsa, at i-verify ang HS256, RS256, ES256 o EdDSA signature sa iyong browser.

Ang mga token ay mga kredensyal. Nagde-decode at nagve-verify ang tool na ito ng mga token sa iyong browser at hindi ito ipinapadala kahit saan.

I-verify ang signature

HS256/384/512: ilagay ang shared secret. RS, PS, ES (256/384/512) at EdDSA: i-paste ang public key bilang PEM (public key, RSA public key o certificate) o JWK (hinahanap sa JWK Set ayon sa kid).

Paano mag-decode ng JWT

  1. I-paste ang token sa JSON Web Token. Gumagana rin ang buong Authorization: Bearer …: aalisin ang prefix na Bearer at ang mga line break.
  2. Dine-decode ang token habang nagta-type ka (o i-click ang I-decode). Lalabas ang Header at Payload bilang naka-format na JSON, bawat isa ay may sariling button na Kopyahin.
  3. Basahin ang talahanayan ng Mga time claim: ipinapakita ang exp, nbf at iat kasama ang orihinal na halaga, ang petsa sa time zone mo, ang relatibong oras (“sa loob ng 3 oras”, “2 araw na ang nakalipas”) at isang status tulad ng Expired na o Hindi pa valid.
  4. Tingnan ang mga babala sa itaas ng resulta, halimbawa kapag none ang alg o kapag mukhang millisecond ang isang petsa.
  5. Para suriin ang signature, ilagay ang key sa I-verify ang signature at i-click ang I-verify ang signature.

Hindi pareho ang pag-decode at pag-verify

Ang JWT ay may tatlong bahaging Base64url na pinaghihiwalay ng mga tuldok: header.payload.signature. Ang header at payload ay naka-encode lang, hindi naka-encrypt, kaya mababasa ito ng sinumang may hawak ng token, at kaya ng tool na ito na mag-decode ng anumang token nang walang key. Ibig sabihin din nito na walang pinatutunayan ang na-decode na payload: maaaring may nagbago nito. Ang valid na signature lang ang nagpapakitang inilabas ang token ng may hawak ng key at hindi ito nabago mula noon. Kaya “Na-decode (hindi pa na-verify ang signature)” ang nakasulat hangga’t hindi mo pa ito nave-verify.

Ang token na may limang bahagi ay isang JWE (naka-encrypt na JWT); hindi mababasa ang laman nito kung walang decryption key, at sasabihin iyon ng tool.

Pag-verify ng signature

  • HS256, HS384, HS512 (HMAC): ilagay ang shared Secret. Gamitin ang Format ng secret para sabihin kung plain text (UTF-8) ito o Base64/Base64url, dahil may mga provider na nag-iimbak ng secret sa Base64. Puwede ka ring mag-paste ng JWK na uri ng oct. Kung mas maikli ang secret kaysa sa hash output (32 byte para sa HS256), ipapaalala ng tool na kulang ito sa minimum ng RFC 7518.
  • RS256/384/512, PS256/384/512, ES256/384/512 at EdDSA: i-paste ang Public key (PEM o JWK). Tinatanggap na PEM block ang PUBLIC KEY, RSA PUBLIC KEY at CERTIFICATE (binabasa ang key mula sa X.509 certificate). Gumagana rin ang JWK o buong JWK Set: ginagamit ang key na tugma ang kid sa header. Tinatanggihan ang mga private key; hindi kailanman kailangan ng verifier ang isa. Sinusuportahan ng EdDSA ang Ed25519 sa mga browser na may ganitong suporta sa Web Crypto.

Ginagamit ng pag-verify ang Web Crypto API ng browser. Ang resultang “Hindi valid ang signature” ay nangangahulugang mali ang key o binago ang token. Tandaan na kinukuha ang algorithm mula sa header ng token: ang totoong server ay dapat magtakda ng inaasahang algorithm sa configuration nito, kung hindi ay maaaring pumili nito ang umaatake.

Mga paalala sa seguridad

  • Mga kredensyal ang mga token. Ang sinumang may hawak ng valid na access token ay kadalasang nakakagawa ng kahit ano bilang may-ari nito hanggang mag-expire ito. Nagde-decode at nagve-verify ang tool na ito ng lahat sa iyong browser at hindi ipinapadala kahit saan ang token o ang key. Gayunman, iwasang mag-paste ng production token sa mga tool na hindi mo masusuri.
  • alg: none ay nangangahulugang hindi naka-sign ang token. Kahit sino ay puwedeng gumawa ng ganito, at dapat itong tanggihan ng server. Nagpapakita ang tool ng babala at tumatangging “mag-verify” ng ganitong token.
  • Ang pagsusuri sa orasan dito ay gumagamit ng orasan ng iyong computer nang walang palugit; kadalasang pinapayagan ng mga server ang isa o dalawang minutong pagkakaiba ng orasan.
  • Ang mga petsa ng JWT (NumericDate) ay segundo mula Enero 1, 1970 UTC. Ang 13-digit na halaga ay malamang na millisecond, na karaniwang bug.

Mga madalas itanong

Masasabi ba ng tool na ito kung valid ang isang token?

Masasabi nito kung tugma ang signature sa key na ibinigay mo at kung natutugunan ngayon ang exp at nbf. Nakadepende rin ang pagtanggap sa token sa mga pagsusuring alam lang ng server: ang inaasahang issuer (iss), audience (aud), algorithm at revocation.

Bakit pumapalya ang verification kahit tama ang secret?

Suriin ang Format ng secret: ang Base64 secret na tinype bilang text ay magbibigay ng ibang key. Tiyakin ding walang nadagdag na space o line break sa secret, dahil byte por byte ang paghahambing sa mga HMAC key.

Ano ang pagkakaiba ng RS256, PS256 at ES256?

Pawang public-key signature na may SHA-256 ang tatlo. Gumagamit ang RS256 ng RSA na may PKCS#1 v1.5 padding, ang PS256 ay RSA na may PSS padding, at ang ES256 ay ECDSA sa P-256 curve, na nagbibigay ng mas maiikling signature.

Saan ko makikita ang public key ng isang provider?

Naglalathala ang mga identity provider ng JWKS (JSON Web Key Set), na kadalasang naka-link sa /.well-known/openid-configuration sa ilalim ng jwks_uri. Buksan ito mismo at i-paste ang JSON dito; pipiliin ng tool ang key ayon sa kid at hindi ito kailanman kukuha ng anuman mula sa internet.

Ligtas ba ang pag-paste ng token ko rito?

Nananatili sa iyong device ang token: lokal ang pag-decode at pag-verify at walang ina-upload. Para sa dagdag na ingat, gumamit ng expired o test na token kung istruktura lang ang kailangan mong suriin.