Dekode JWT — Baca Header dan Payload
Dekode JWT untuk membaca header dan payload-nya dengan jelas — seketika dan privat di browser Anda.
Tokennya tetap di perangkat Anda
Tidak ada yang perlu dihapus kemudian
Dibangun untuk kredensial hidup
Jalan di semua browser modern
Cara kerjanya
- 1
Tempel tokennya
Seluruhnya, termasuk kedua titiknya — tiga bagiannya dipisahkan oleh titik-titik itu.
- 2
Baca klaimnya
Header di satu sisi, payload di sisi lain, dengan cap waktu yang sudah dikonversi menjadi tanggal.
- 3
Periksa yang Anda cari
Biasanya kedaluwarsanya, penerbitnya, audiensnya, atau pengguna mana yang sebenarnya dimaksud token itu.
Mengapa memakai alat ini
Header dan payload berdampingan
Algoritme dan petunjuk kuncinya di samping klaim; di situlah sebagian besar pertanyaan penelusuran galat terjawab.
Cap waktu dalam bentuk terbaca
`exp`, `iat`, dan `nbf` ditampilkan sebagai tanggal alih-alih angka sepuluh digit yang harus Anda konversi.
Kedaluwarsa diadu dengan sekarang
Anda langsung melihat apakah tokennya masih di dalam jendelanya, tanpa melakukan aritmetika.
Jujur soal verifikasi
Alat ini membongkar; ia tidak memverifikasi tanda tangan, dan ia mengatakannya alih-alih menyiratkan tokennya sah.
Tidak ada yang dikirimkan
Tokennya diurai di browser Anda — kredensial sesi yang masih berfungsi tak pernah sampai ke server.
Gratis tanpa akun
Tanpa pendaftaran, tanpa watermark, dan tanpa batas berapa token yang Anda periksa.
Membongkar bukan memverifikasi, dan perbedaannya adalah keseluruhan model keamanannya
Sebuah JWT punya tiga bagian yang dipisahkan titik, dan dua yang pertama hanyalah teks base64url. Siapa pun yang memegang tokennya bisa membaca header dan payload-nya dalam satu langkah — itulah yang dilakukan halaman ini — dan itu tak memerlukan kunci, izin, maupun rahasia. Verifikasi adalah operasi yang sepenuhnya terpisah: menghitung ulang tanda tangan atas dua bagian pertama memakai kunci penerbitnya dan memeriksa bahwa ia cocok dengan yang ketiga. Hanya verifikasi yang memberi tahu Anda bahwa tokennya autentik dan tak diubah. Sebuah pembongkar memberi tahu Anda apa yang diklaim sebuah token, tak pernah apakah klaimnya benar, karena siapa pun bisa merangkai token yang mengatakan apa pun yang ia mau. Kalau Anda sedang menelusuri galat, membongkar menjawab pertanyaan Anda. Kalau Anda sedang memutuskan apakah memercayai sebuah permintaan, membongkar tak menjawab apa pun.
Payload-nya bisa dibaca siapa saja, dan orang terus-menerus melupakannya
Ini mengikuti dari yang di atas dan layak dinyatakan tersendiri, karena ia sumber pembocoran data yang nyata. Payload JWT itu terkode, bukan terenkripsi. Tiap klaim di dalamnya — pengenal pengguna, alamat surel, peran, tenant, bidang internal apa pun yang terasa praktis untuk disertakan — terlihat oleh siapa pun yang memegang tokennya, termasuk browser tempat ia diterbitkan, tiap pengaya yang berjalan di browser itu, dan siapa pun yang memperolehnya kemudian. Tanda tangannya melindungi payload dari diubah, bukan dari dibaca. Jadi token adalah tempat yang masuk akal untuk sebuah pengenal dan sebuah peran, dan tempat yang buruk untuk sebuah alamat, nomor telepon, status lisensi yang mungkin memalukan bagi seseorang, atau apa pun yang takkan Anda cetak di bagian luar amplop. Kalau sebuah klaim harus tetap privat, ia bukan milik tokennya.
Jangan pernah biarkan token memberi tahu Anda cara memverifikasinya
Kerentanan JWT yang paling terkenal semuanya berbagi satu bentuk: sebuah pustaka membaca bidang `alg` dari header lalu memercayainya. Versi historisnya adalah `alg: none`, yang menyatakan tokennya tak bertanda tangan — pemverifikasi yang menghormatinya menerima apa saja, dan penyerang tinggal menulis payload-nya sendiri lalu mencopot tanda tangannya. Versi yang lebih halus adalah kekeliruan algoritme: token bertanda tangan HMAC disodorkan ke server yang mengharapkan RSA; kalau kodenya melewatkan kunci publik RSA sebagai rahasia HMAC, dan kunci publik itu diterbitkan, penyerang bisa menandatangani token dengannya. Keduanya diperbaiki dengan cara yang sama: kode pemverifikasi memutuskan sendiri algoritme dan kunci mana yang ia terima, dan menolak segala yang lain, alih-alih membaca jawabannya dari bagian tak tepercaya token yang sedang ia periksa.
Cap waktunya dalam detik, dan tak ada yang menegakkannya dengan sendirinya
Tiga klaim mengendalikan jendela sahnya sebuah token. `exp` adalah kedaluwarsanya, `nbf` adalah waktu sebelum mana ia tak boleh diterima, dan `iat` adalah kapan ia diterbitkan. Ketiganya adalah detik sejak epoch Unix, yang menjegal siapa pun yang bekerja di bahasa yang cap waktu bawaannya milidetik — tokennya berakhir entah sudah kedaluwarsa atau sah untuk lima puluh ribu tahun ke depan, dan kedua kekeliruan itu cukup lazim untuk diperiksa lebih dulu. Poin yang lebih penting: ini klaim, bukan penegakan. Tak ada apa pun pada tokennya yang berhenti bekerja ketika `exp` terlewati; kedaluwarsa hanya ada kalau kode pemverifikasi membandingkannya dengan waktu sekarang dan menolak permintaannya. Pembongkar yang menunjukkan token kedaluwarsa memberi tahu Anda maksud penerbitnya, bukan apa yang akan dilakukan server tertentu terhadapnya.
JWT tak bisa dicabut, dan itulah kesepakatan yang Anda terima
Alasan memakai token ini adalah verifikasi tanpa keadaan: sebuah server bisa memastikan sebuah permintaan autentik hanya dengan sebuah kunci, tanpa menengok basis data, dan itulah yang membuatnya menskala lintas layanan. Konsekuensi langsungnya adalah tak ada yang bisa dihapus. Sesi yang tersimpan di basis data berakhir begitu Anda menghapus barisnya; token bertanda tangan tetap sah sampai kedaluwarsa apa pun yang terjadi di sisi penerbitnya, karena tak ada yang berkonsultasi kepada penerbitnya. Token yang bocor karena itu bisa dipakai sampai ia kedaluwarsa, dan justru itulah sebabnya token akses seharusnya berumur pendek — menit, bukan minggu — dengan token penyegar berumur lebih panjang yang bisa dicabut karena ia memang diperiksa terhadap penyimpanan. Kalau token akses Anda bertahan sebulan, Anda memiliki semua kerugian tanpa-keadaan dan tak satu pun keamanan sesi.
Kenapa inilah kasus paling tajam untuk membongkar secara lokal
Hampir tiap alat teks lain menangani bahan yang sensitif karena keadaan. JWT sensitif menurut definisinya: ia adalah kredensialnya, dan token yang sah dan belum kedaluwarsa cukup untuk bertindak sebagai pengguna yang menjadi tujuan penerbitannya. Menempelkan satu ke pembongkar yang dihosting mengirimkan kredensial autentikasi yang masih berfungsi kepada pihak ketiga, lewat kanal yang tak meninggalkan jejak, demi membaca bidang-bidang yang bisa Anda baca secara lokal. Kalau tokennya masih bersisa berjam-jam, siapa pun yang menerimanya bisa memakainya. Halaman ini mengurai di browser dan tak mengirimkan apa pun, yang bisa Anda pastikan di tab Network pada developer tools — dan kalau Anda pernah menempelkan token produksi ke sebuah situs untuk memeriksa kedaluwarsanya, memperlakukan token itu sebagai telah bocor adalah tanggapan yang benar.
Kesalahan umum yang sebaiknya dihindari
- Menganggap pembongkaran yang berhasil sebagai token yang sah. Membongkar tak butuh kunci dan tak membuktikan apa pun; hanya verifikasi tanda tangan dengan kunci penerbitnya yang menetapkan keautentikannya.
- Menaruh data privat di payload. Ia terkode, bukan terenkripsi — tanda tangannya mencegahnya diubah, bukan dibaca, jadi siapa pun yang memegang tokennya melihat tiap klaim.
- Membiarkan tokennya memilih algoritme verifikasinya. Membaca `alg` dari header adalah cara kerja serangan `alg: none` dan kekeliruan algoritme; pemverifikasi harus menetapkan algoritme dan kunci di muka.
- Menulis `exp` dalam milidetik. Cap waktu JWT adalah detik sejak epoch, jadi nilai dalam milidetik menghasilkan token yang sah selama puluhan ribu tahun — atau yang sudah kedaluwarsa.
- Menempelkan token produksi ke pembongkar yang dihosting. Itu kredensial hidup, penempelannya tak meninggalkan jejak, dan siapa pun yang menerimanya bisa memakainya sampai ia kedaluwarsa.
Perbandingan
| Aspek | Alat ini | Pembongkar daring | Pemanggilan pustaka |
|---|---|---|---|
| Token dikirim ke server | Tidak pernah | Umumnya ya | Tidak |
| Cap waktu ditampilkan sebagai tanggal | Ya | Kadang | Anda yang memformat |
| Jelas bahwa ia tak memverifikasi | Ya | Sering kabur | Eksplisit di API-nya |
| Jalan tanpa membuka proyek | Ya | Ya | Tidak |
| Akun atau pendaftaran | Tidak perlu | Sering diminta | Tidak perlu |
| Harga | Gratis | Gratis / paket berbayar | Gratis |
Fitur
Penguraian penuh tiga bagian
Header, payload, dan segmen tanda tangan ditampilkan terpisah sebagaimana formatnya mendefinisikannya.
base64url ditangani dengan benar
JWT memakai alfabet aman-URL tanpa padding, yang dikelirukan pembongkar Base64 biasa.
Klaim standar diberi label
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, dan `jti` diberi nama alih-alih dibiarkan sebagai singkatan.
Token cacat ditandai
Segmen yang hilang atau pengodean tak sah dilaporkan alih-alih menghasilkan omong kosong sebagian.
Unicode di klaim dipertahankan
Nama dan nilai dalam bahasa Arab, Turki, atau aksara apa pun terbongkar utuh.
Seketika, tanpa permintaan
Penguraiannya terjadi saat Anda menempel, tanpa ada yang diambil dan tanpa ada yang dikirim.
Tanpa instalasi
Tanpa pustaka, tanpa runtime, tanpa dependensi — jalan di halaman web.
Ramah Arab dan RTL
Antarmuka lengkap dalam delapan bahasa, termasuk Arab kanan-ke-kiri.
Aman secara bawaan
Disajikan lewat HTTPS, tanpa pelacakan konten dan tanpa unggahan ke pihak ketiga.
Siapa yang memakainya
Pengembang
Memeriksa kenapa sebuah panggilan API ditolak — biasanya token kedaluwarsa atau audiens yang keliru.
Insinyur keamanan
Memeriksa klaim dan algoritme sebuah token yang ditemukan di log atau laporan kutu.
Integrator API
Memastikan cakupan dan peran apa yang sebenarnya diterbitkan penyedia sebelum menulis kode terhadapnya.
Insinyur dukungan
Membaca token kiriman pelanggan untuk melihat akun dan tenant mana yang menjadi miliknya.
Pertanyaan yang Sering Diajukan
Tidak. Semuanya berjalan lokal di browser Anda — teks Anda tidak pernah diunggah, disimpan, atau dibagikan.
Ya — sepenuhnya gratis, tanpa akun dan tanpa batas.