TK TaskKit
Tools Developer

JWT Decoder

Decode JSON Web Token, inspeksi claim, dan periksa kedaluwarsa tanpa meng-upload token.

DecodeEncode
Token
Terdecode

Paste JWT untuk menginspeksi header, payload, dan claim terdaftarnya.

Token HS256 yang ditandatangani dengan secret "taskkit-demo-secret" — beralih ke mode Verify dan paste secret untuk mengetes verifikasi.

Input tetap di perangkat ini. Setiap tool developer di TaskKit berjalan sepenuhnya di browser kamu. Token, payload, dan teks yang di-paste tidak ditransmisikan ke server TaskKit atau pihak ketiga.

Apa yang dilakukan tool ini

Decoder JWT ini membagi JSON Web Token menjadi tiga bagiannya — header, payload, dan signature — dan menampilkan konten yang ter-decode beserta claim terdaftar (iss, sub, aud, exp, iat, nbf, jti). Jendela validitas dihitung dari exp dan nbf sehingga kamu dapat melihat sekilas apakah token masih dalam masa berlaku.

Tool ini juga menawarkan verifikasi signature untuk algoritma yang sebenarnya digunakan API: HS256/384/512 dengan shared secret, RS256/384/512 dan PS256/384/512 dengan public key RSA, ES256/384/512 dengan public key EC, dan EdDSA dengan key Ed25519. Public key dapat di-paste sebagai JWK, JWKS lengkap (TaskKit memilih key yang tepat dengan mencocokkan kid token), blok PEM SPKI, public key PEM PKCS#1 RSA, sertifikat X.509 (public key diekstrak otomatis), atau — untuk EdDSA — sebagai 64 karakter hex atau 43 karakter base64url. Jika header token berisi array x5c (chain sertifikat X.509 inline), sertifikat leaf digunakan otomatis saat field key kosong.

Kapan menggunakannya

  • Menginspeksi token yang dikembalikan oleh auth server kamu selama development lokal.
  • Mengkonfirmasi bahwa claim token pihak ketiga sesuai dengan yang diharapkan client kamu.
  • Memverifikasi bahwa token yang di-refresh ditandatangani dengan key yang sama seperti sebelumnya.
  • Memeriksa kedaluwarsa saat sesuatu berhenti bekerja tepat di tengah malam UTC.

Cara kerjanya

Decoding hanya Base64URL — spec JWT menggunakan Base64 URL-safe dengan padding dihapus. Header dan payload adalah JSON; signature adalah byte mentah. Verifikasi menggunakan crypto.subtle.verify, API WebCrypto bawaan browser, dengan algoritma diambil dari header. EdDSA melalui @noble/ed25519 (juga khusus browser) karena dukungan WebCrypto untuk Ed25519 masih belum merata di browser.

Input key permisif soal format. Key simetris (HS*) diimpor sebagai byte mentah atau JWK. Key asimetris (RS/PS/ES) diterima sebagai JWK, JWKS (kid token memilih key yang tepat — set dengan satu key digunakan langsung), PEM SPKI (BEGIN PUBLIC KEY), public key PEM PKCS#1 RSA (BEGIN RSA PUBLIC KEY), atau sertifikat X.509 (BEGIN CERTIFICATE) — TaskKit menelusuri sertifikat dengan reader ASN.1 internal yang kecil untuk mengekstrak SubjectPublicKeyInfo yang embedded. Key EdDSA dapat berupa JWK, JWKS, SPKI PEM, 64 karakter hex, atau 43 karakter base64url.

Tidak ada bagian dari tool ini yang sisi server. Token tidak pernah meninggalkan browser kamu, key tidak pernah meninggalkan browser kamu, dan tidak ada telemetri pada keduanya. Jika kamu paste token production untuk debug sesuatu, auditor kamu tidak akan melihat request ke taskkit.net yang membawa token itu.

Catatan

Mengapa "alg: none" ditolak bahkan saat token tervalidasi? Karena tidak ada JWT dunia nyata yang seharusnya menggunakan alg: none. Itu adalah vektor serangan yang dikenal: jika verifier kamu menerima none, attacker dapat menghapus signature dan memalsukan payload apapun. Kami menampilkannya sebagai error daripada melewatkannya secara diam-diam.

Bisakah saya memverifikasi token Microsoft / Google / Auth0? Ya — ambil JWKS issuer (mis. https://login.microsoftonline.com/common/discovery/v2.0/keys) dan paste seluruh dokumen JSON di field key. TaskKit membaca header kid token dan otomatis memilih JWK yang sesuai; tidak perlu pencarian manual.

HS256 vs RS256 — yang mana yang harus saya gunakan? RS256 (atau ES256) untuk apapun yang akan diverifikasi pihak eksternal, karena mereka hanya butuh public key. HS256 baik-baik saja untuk service-to-service saat kedua sisi memegang secret yang sama.

Token saya memiliki header x5c — apakah itu berarti saya mempercayai sertifikat embedded? TaskKit akan menggunakan sertifikat leaf dari x5c untuk memverifikasi signature saat kamu tidak paste key, sehingga kamu dapat mengkonfirmasi konten token tidak dirusak. Itu tidak memvalidasi chain kembali ke CA — itu memerlukan trust root dan di luar lingkup di sini. Chip hasil menampilkan « diverifikasi dengan sertifikat x5c dari header token (chain tidak divalidasi) » sehingga kamu tidak salah mengiranya sebagai vonis trust end-to-end.

Tools terkait