Dekoder JWT

Mendekode JWT hanya membaca isinya; tanda tangan dan waktu yang menentukan apakah token layak dipercaya

JWT (JSON Web Token) adalah string yang terdiri dari tiga bagian yang dipisahkan dua titik (.): header, payload, dan tanda tangan. Dua bagian pertama adalah JSON yang ditulis dalam Base64url, sehingga siapa pun dapat mendekode dan membacanya tanpa kunci. Karena itu, isi token yang terlihat setelah didekode belum membuktikan bahwa token itu asli atau masih boleh dipakai. Server menerima token hanya setelah memeriksa secara berurutan apakah tanda tangan cocok, apakah waktu kedaluwarsa (exp) belum lewat, dan apakah penerbit (iss) serta audiens (aud) sesuai dengan yang diharapkan.

Alat ini langsung mendekode token yang ditempel dan menampilkan nilai serta arti header dan payload dalam tabel. Alat ini juga menelusuri empat tahap pemeriksaan (format, tanda tangan, waktu, penerbit dan audiens) dengan urutan yang sama, lalu menunjukkan di tahap mana token tertahan. Jika kunci rahasia atau kunci publik (PEM, JWK, JWKS) diisi, tanda tangan benar-benar diverifikasi, dan sisa waktu hingga exp berkurang per detik pada garis waktu. Token dan kunci hanya dihitung di dalam browser dan tidak dikirim ke mana pun.

Kapan perlu mendekode JWT sendiri

• Saat API mengembalikan 401 Unauthorized: penyebab penolakan biasanya token kedaluwarsa (exp), token untuk layanan lain (aud), atau kunci yang diganti (kid). Tempel token, dan terlihat langsung di tahap mana dari empat tahap itu token tertahan.
• Saat login berakhir lebih cepat dari perkiraan: selisih iat dan exp adalah masa berlaku token. Access token sering diberi masa berlaku pendek, misalnya 15 menit atau 1 jam, sehingga pengaturannya dapat dicek dari masa berlaku dan sisa waktu di layar.
• Saat memasang login OpenID Connect: periksa apakah nilai seperti iss, aud, nonce, dan email_verified pada ID token sesuai harapan. Jika JSON dari jwks_uri penyedia identitas ditempel utuh, tanda tangan diverifikasi dengan kunci publik yang kid-nya sama.
• Saat mencari tahu mengapa izin tidak ada: klaim seperti scope, roles, dan groups ditampilkan dalam chip agar mudah dilihat apakah izin yang diperlukan ada di dalamnya. Arti nilainya ditentukan layanan penerbit, jadi bandingkan dengan konfigurasi server.
• Saat jam server dan jam perangkat berbeda: jika token yang baru diterbitkan sudah tampak "belum berlaku" atau "kedaluwarsa", penyebabnya bisa selisih jam. Ubah toleransi antara 0 detik, 60 detik, dan 5 menit untuk melihat perubahan hasil penilaian.
• Saat membutuhkan token uji: ubah payload lewat "Ubah JSON" lalu tandatangani ulang dengan kunci rahasia untuk membuat token dengan nilai yang diinginkan. Anda juga langsung dapat melihat bahwa mengubah isi tanpa kunci membuat tanda tangan tidak cocok.

Cara memakai

1. Isi token: tempel JWT pada kolom token. Meskipun tercampur teks lain, seperti header Authorization: Bearer …, JSON respons token ({"access_token": "…", "id_token": "…"}), atau #id_token=… pada URL callback, hanya bagian token yang dicari dan dibaca. Jika ada beberapa token, pilih lewat chip.
2. Periksa bagian token: teks token diberi warna berbeda untuk header, payload, dan tanda tangan, dan jumlah byte tiap bagian ditampilkan pada bilah bagian. Saat kursor diarahkan ke baris tabel, karakter token tempat nilai itu berada disorot.
3. Periksa waktu: kolom waktu berlaku menampilkan sisa waktu hingga kedaluwarsa, waktu iat, nbf, dan exp dalam zona waktu perangkat, serta masa berlaku token. Pilih toleransi yang sesuai dengan pustaka yang dipakai server.
4. Verifikasi tanda tangan: jika alg dari keluarga HS seperti HS256, isi kunci rahasia; jika dari keluarga RS, PS, ES, atau EdDSA, isi kunci publik. Dengan mengisi penerbit dan audiens yang diharapkan server, pemeriksaan berlanjut sampai tahap keempat.
5. Ubah isi: tekan "Ubah JSON" pada bagian "Isi" untuk mengubah header dan payload secara langsung. Jika kolom verifikasi tanda tangan berisi kunci rahasia HS atau kunci privat, token yang dihasilkan ditandatangani ulang dengan isi yang sudah diubah.

Tiga bagian yang dipisahkan dua titik

Header dan payload adalah JSON UTF-8 yang diubah menjadi Base64url. Base64url memakai - dan _ sebagai ganti + dan / pada Base64 biasa, serta membuang = di akhir (RFC 7515 bagian 2), sehingga dapat langsung ditaruh di URL atau header HTTP. Tanda tangan adalah byte hasil perhitungan terhadap seluruh teks "header.payload" dengan kunci, yang ditulis dengan cara yang sama; karena itu, perubahan satu karakter saja pada header atau payload membuatnya tidak cocok. Tabel berikut membagi token HS256 yang dibuat dengan kunci rahasia demo-secret-for-roberin-jwt-2026.

Karena 3 byte menjadi 4 karakter, bagian Base64url sekitar sepertiga lebih panjang daripada JSON aslinya. Panjang bagian tanda tangan ditentukan algoritma: HS256 sebesar 32 byte (43 karakter), RS256 sepanjang kunci RSA (kunci 2048 bit menghasilkan 256 byte, 342 karakter), dan ES256 sebesar 64 byte (86 karakter). Jika ada lima bagian, token itu adalah JWE terenkripsi (RFC 7516). Header JWE dapat dibaca, tetapi keempat bagian lainnya tidak dapat didekripsi tanpa kunci penerima.

Klaim yang sering muncul dan hal yang perlu diperiksa

Setiap entri pada payload disebut klaim. Tujuh klaim yang didaftarkan RFC 7519 dan nama yang ditetapkan OpenID Connect sudah memiliki arti baku, sedangkan nama lain adalah nilai yang ditetapkan sendiri oleh layanan penerbit (Private Claim). Kolom "Yang diperiksa" pada tabel adalah tugas server yang menerima token.

Cara membaca exp, nbf, iat dan toleransi selisih jam

Ketiga waktu itu adalah detik yang dihitung sejak 1 Januari 1970 pukul 00.00 UTC (NumericDate pada RFC 7519). Jika momen yang sama ditulis dalam WIB, waktunya bertambah 7 jam dari UTC. Nilai yang ditulis dalam milidetik berjumlah 13 digit; jika dibaca sebagai detik, hasilnya puluhan ribu tahun lagi sehingga token praktis tidak pernah berakhir. Alat ini memberi peringatan jika menemukan nilai seperti itu.

Jam server penerima dan jam server penerbit dapat berselisih beberapa detik hingga beberapa menit. RFC 7519 menyebutkan bahwa saat memeriksa exp dan nbf, toleransi kecil yang "biasanya tidak lebih dari beberapa menit" boleh diberikan. Nilai default sebenarnya berbeda di setiap pustaka, sehingga token yang sama bisa diterima oleh satu server dan ditolak oleh server lain.

Penilaian alat ini sama dengan jsonwebtoken. Jika waktu sekarang (detik dibulatkan ke bawah) sama dengan atau melewati exp + toleransi, token kedaluwarsa; jika nbf lebih lambat daripada waktu sekarang + toleransi, token belum berlaku. Jika waktu kedaluwarsa sudah lewat tetapi masih dalam toleransi, tahap waktu dianggap lolos dan sisa toleransi ditampilkan.

Verifikasi tanda tangan: kunci yang diperlukan tiap algoritma

alg pada header adalah nama metode yang dipakai untuk menandatangani. Penerima tidak boleh langsung memercayai nilai ini, jadi server harus menetapkan algoritma yang diizinkan terlebih dahulu dan menolak yang lain (RFC 8725 3.1). Alat ini menunjukkan jenis kunci yang sesuai dengan alg, dan memberi tahu alasannya jika kunci yang tidak cocok dimasukkan.

Jika kunci privat dimasukkan, kunci publiknya diambil untuk verifikasi, tetapi untuk verifikasi sebenarnya kunci publik saja sudah cukup. Saat menyalin kunci rahasia, baris baru sering ikut terbawa di akhir; jika token tidak cocok apa adanya tetapi cocok setelah spasi di awal dan akhir dibuang, alat ini memberi tahu hal itu. Untuk token ES dengan tanda tangan berformat DER (diawali 0x30), penyebabnya ditampilkan tersendiri karena token itu dibuat keliru oleh pustaka lain.

Mengapa jalur pemeriksaan sama dengan urutan pemeriksaan di server

RFC 7519 bagian 7.2 menetapkan urutan saat menerima JWT: memisahkan bagian, mendekode Base64url dan JSON, lalu memverifikasi tanda tangan. Jika gagal di tahap mana pun, token harus ditolak. Selain itu, RFC 8725 mewajibkan pemeriksaan bahwa kunci penanda tangan milik penerbit jika ada iss (3.8), dan jika satu penerbit melayani beberapa aplikasi, penolakan token yang aud-nya tidak ada atau bukan untuk Anda (3.9). Empat tahap pada alat ini mengikuti urutan tersebut, dan alasan tahap pertama yang tertahan ditulis pada baris penilaian. Jika tanda tangan belum diverifikasi, tahap lain yang lolos tetap ditandai "belum diperiksa".

Apakah izinnya benar, apakah sesinya sudah logout, atau apakah jti yang sama dipakai ulang tidak dapat diketahui dari token saja. Syarat seperti ini diperiksa server dengan catatan dan konfigurasinya sendiri, sehingga lolos di keempat tahap hanya berarti "syarat pada token itu sendiri terpenuhi".

Mengubah JSON dan menandatangani ulang

Jika header atau payload diubah lewat "Ubah JSON", alat ini membuat token baru dan memasukkannya ke kolom token. Jika kolom verifikasi tanda tangan berisi kunci rahasia HS atau kunci privat RS, PS, ES, atau Ed25519 (PKCS#8, PKCS#1, kunci privat EC, atau JWK yang memuat d), token ditandatangani ulang dengan kunci itu. Jika hanya ada kunci publik atau tidak ada kunci sama sekali, tanda tangan awal dipasang apa adanya sehingga tahap tanda tangan berubah menjadi tidak cocok. Contoh "Token yang diubah" adalah kasus ini: nilai role diubah dari user menjadi admin, tetapi tanda tangannya tetap yang lama, sehingga langsung ketahuan saat diperiksa dengan kunci rahasia.

Tombol "iat ke sekarang, exp 15 menit lagi, 1 jam lagi, 1 hari lagi" mengubah waktu token uji sekaligus. Jika ada nbf, nbf juga disesuaikan ke waktu sekarang. JSON yang diubah hanya dibuang spasinya agar menjadi satu baris, sehingga urutan kunci dan penulisan angka tetap seperti yang diketik.

Kesalahan umum dan serangan yang dikenal

• Server yang menerima alg none: token tanpa tanda tangan dapat dibuat siapa saja. Ada pustaka yang bahkan menerima None atau NONE yang hanya berbeda huruf besar-kecil, jadi serangan ini harus dicegah dengan daftar algoritma yang diizinkan (RFC 8725 2.1).
• Mengganti token RS256 menjadi HS256: penyerang mengubah alg menjadi HS256 lalu menandatangani dengan kunci publik server sebagai kunci rahasia HMAC. Serangan ini terhalang jika satu kunci hanya dipakai untuk satu algoritma. Alat ini memberi tahu bahwa bentuknya demikian bila kunci publik dimasukkan untuk token HS.
• Kunci rahasia yang mudah diingat: jika satu token HS256 jatuh ke tangan penyerang, kunci rahasia dapat ditemukan dengan serangan kamus. Buat kunci rahasia secara acak (RFC 8725 3.5) dengan panjang minimal sepanjang keluaran hash, yaitu 32 byte untuk HS256 (RFC 7518 3.2).
• Server yang tidak memeriksa aud: token yang diterbitkan penerbit yang sama untuk layanan lain akan diterima begitu saja. Kesalahan memakai ID token untuk mengakses API juga harus dicegah dengan alasan yang sama.
• Pencarian kunci yang langsung memakai kid atau jku: jika kid langsung dimasukkan ke jalur file atau SQL, atau kunci diambil dari alamat jku pada header, verifikasi akhirnya memakai kunci pilihan penyerang (RFC 8725 3.10).
• Data pribadi di dalam payload: JWT bertanda tangan tidak terenkripsi. Jika email atau nomor telepon dimasukkan, nilainya dapat dibaca di log dan browser mana pun yang dilewati token.
• Karakter yang ikut tersalin: jika Bearer, tanda kutip, atau baris baru ikut masuk, server tidak dapat membaca token. Alat ini membuang karakter seperti itu sebelum membaca, lalu menuliskan apa yang dibuang.

Batasan dan catatan

• JWE (lima bagian) hanya dibaca headernya dan tidak didekripsi. Alat ini juga tidak membaca JWT bersarang, token dengan b64 bernilai false (RFC 7797), maupun JWS berformat serialisasi JSON.
• Verifikasi tanda tangan memakai Web Crypto di browser. ES256K dan Ed448 tidak dapat diperiksa, dan pada browser lama yang tidak mendukung Ed25519 ditampilkan keterangan bahwa pemeriksaan tidak dapat dilakukan.
• Kunci tidak diambil dari alamat jku atau x5u, maupun dari jwks_uri penyedia identitas. Kunci publik harus ditempel sendiri; ini pilihan agar token tidak dikirim ke luar.
• Penilaian waktu memakai jam perangkat ini sebagai acuan. Jika jam perangkat salah, sisa waktu dan penilaiannya ikut salah sebesar selisih itu.
• Meskipun keempat tahap lolos, izin, status logout, dan pemakaian ulang hanya dapat diketahui server. Sebaiknya jangan menempelkan kunci rahasia produksi dan token pengguna sungguhan; gunakan kunci dan token uji.

Acuan: aturan JWT, JWS, JWE, JWK, dan JWA mengacu pada RFC 7519, 7515, 7516, 7517, dan 7518; anjuran keamanan pada RFC 8725; nama Ed25519 pada RFC 9864; klaim ID token pada OpenID Connect Core 1.0. Nilai default toleransi dicek pada kode sumber tiap pustaka pada 22 Oktober 2026. Token dan waktu pada tabel dicek menghasilkan nilai yang sama dengan alat ini dan Python PyJWT 2.13.

Sumber

• 01IETF — RFC 7519: JSON Web Token (JWT)Bagian 2 NumericDate, bab 4 keunikan nama klaim, 4.1 klaim terdaftar (iss, sub, aud, exp, nbf, iat, jti), 4.1.4 toleransi exp, 7.2 urutan validasi
• 02IETF — RFC 7515: JSON Web Signature (JWS)Bagian 2 Base64url (= di akhir dibuang), bab 4 keunikan nama header, 4.1 header terdaftar (alg, kid, jku, x5u, typ, cty, crit)
• 03IETF — RFC 7518: JSON Web Algorithms (JWA)3.2 panjang kunci HMAC, 3.3 dan 3.5 RSA 2048 bit dan panjang salt PSS, 3.4 tanda tangan ECDSA R‖S
• 04IETF — RFC 8725: JSON Web Token Best Current Practices2.1 none dan penggantian algoritma, 2.2 kunci simetris yang lemah, 3.1 algoritma yang diizinkan, 3.8 kunci milik penerbit iss, 3.9 pemeriksaan aud, 3.10 kid, jku, x5u, 3.11 typ
• 05IETF — RFC 7516: JSON Web Encryption (JWE)7.1 lima bagian pada serialisasi Compact
• 06IETF — RFC 7517: JSON Web Key (JWK)JWK dan JWK Set (array keys), parameter kid, use, alg
• 07IETF — RFC 9864: Fully-Specified Algorithms for JOSE and COSEOktober 2025, pendaftaran Ed25519 dan Ed448, EdDSA ditandai tidak digunakan lagi (Deprecated)
• 08OpenID Foundation — OpenID Connect Core 1.0Bagian 2 ID token (auth_time, nonce, acr, amr, azp), 5.1 klaim standar (name, email, email_verified, dll.)
• 09IETF — RFC 9068: JWT Profile for OAuth 2.0 Access Tokenstyp at+jwt, klaim client_id dan scope
• 10PyJWT — jwt/api_jwt.pyNilai default leeway pada decode adalah 0
• 11auth0/node-jsonwebtoken — verify.jsJika clockTolerance tidak ada, nilainya 0; kedaluwarsa jika sekarang ≥ exp + toleransi
• 12Spring Security — JwtTimestampValidatorDEFAULT_MAX_CLOCK_SKEW sebesar 60 detik
• 13Microsoft.IdentityModel.Tokens — TokenValidationParametersDefaultClockSkew sebesar 300 detik (5 menit)
• 14MDN — SubtleCrypto.verify()API Web Crypto untuk memverifikasi tanda tangan HMAC, RSASSA-PKCS1-v1_5, RSA-PSS, ECDSA, dan Ed25519 di browser

Pertanyaan yang sering diajukan

Alat yang dipakai bersama