Cara Men-decode dan Memverifikasi Token JWT di Browser Anda

Jika Anda pernah bekerja dengan sistem autentikasi web modern — OAuth 2.0, OpenID Connect, atau API kustom — Anda hampir pasti pernah menemukan token JWT. Mereka muncul di header Authorization, dalam cookie, di local storage, dan dalam sesi debugging pukul 2 dini hari ketika alur login misterius gagal. Memahami apa yang sebenarnya dikandung JWT, cara membacanya, dan cara mendeteksi masalah umum membuat debugging autentikasi jauh lebih cepat.

Decoder JWT BrowseryTools memungkinkan Anda menempel token JWT apa pun dan langsung melihat header, payload, dan status kedaluwarsa yang telah didekode — semua di browser Anda, dengan token tidak pernah meninggalkan perangkat Anda.

Apa Itu JWT?

JWT singkatan dari JSON Web Token, yang didefinisikan dalam RFC 7519. JWT adalah token yang kompak dan aman untuk URL yang mengenkode sekumpulan klaim — pernyataan tentang subjek, biasanya pengguna — dalam format yang dapat diverifikasi dan dipercaya. Properti kunci JWT adalah bahwa iaself-contained: token itu sendiri membawa semua informasi yang dibutuhkan server untuk mengautentikasi permintaan, tanpa pencarian database.

JWT terlihat seperti ini:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODQyMTkiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmUuZG9lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsidXNlciIsImVkaXRvciJdLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImlhdCI6MTczODM2ODAwMCwiZXhwIjoxNzM4MzcxNjAwLCJqdGkiOiI3ZjNhOWI0Yy0xZDJlLTQ1NmYtYWJjZC04OTAxMjM0NTY3ODkifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Pada pandangan pertama terlihat seperti omong kosong. Namun ia memiliki struktur yang sangat tepat: tiga bagian yang dienkode Base64URL dipisahkan oleh titik. Setiap bagian memiliki tujuan khusus.

Struktur Tiga Bagian: Header.Payload.Signature

Bagian 1: Header

Segmen pertama, sebelum titik pertama, adalah header. Ini adalah objek JSON yang dienkode Base64URL yang mendeskripsikan jenis token dan algoritma penandatanganan. Didekode, header dari contoh di atas terlihat seperti:

{
  "alg": "HS256",
  "typ": "JWT"
}

Kolom alg menentukan algoritma penandatanganan. Nilai umum yang akan Anda temui adalah:

• HS256 — HMAC dengan SHA-256. Menggunakan kunci rahasia bersama. Baik penerbit maupun verifikator harus memiliki rahasia yang sama. Umum dalam aplikasi monolitik.
• RS256 — Tanda tangan RSA dengan SHA-256. Menggunakan pasangan kunci publik/privat. Penerbit menandatangani dengan kunci privat; verifikator memeriksa dengan kunci publik. Umum dalam sistem terdistribusi dan penyedia OAuth.
• ES256 — ECDSA dengan P-256 dan SHA-256. Seperti RS256 tetapi menggunakan kurva eliptik — kunci lebih pendek, tingkat keamanan sama. Lebih disukai dalam sistem berkinerja tinggi modern.
• none — Tanpa tanda tangan. Jangan pernah terima ini dalam produksi. Kerentanan keamanan terkenal muncul ketika server menerima token tanpa tanda tangan karena klien mengubah alg menjadi "none".

Bagian 2: Payload

Segmen kedua adalah payload — data aktual yang dibawa token. Ini juga merupakan objek JSON yang dienkode Base64URL. Payload yang didekode dari contoh kita:

{
  "sub": "usr_84219",
  "name": "Jane Doe",
  "email": "jane.doe@example.com",
  "roles": ["user", "editor"],
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1738368000,
  "exp": 1738371600,
  "jti": "7f3a9b4c-1d2e-456f-abcd-890123456789"
}

Payload berisi dua jenis klaim: klaim terdaftar yang didefinisikan oleh spesifikasi JWT, dan klaim privat/kustom yang ditambahkan oleh aplikasi Anda (seperti name, email, dan roles di atas).

Bagian 3: Signature

Segmen ketiga adalah signature. Dihitung dengan mengambil header yang dienkode Base64URL, sebuah titik, payload yang dienkode Base64URL, dan menandatangani hasilnya dengan algoritma dan kunci yang ditentukan dalam header. Untuk HS256:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Signature memastikan integritas: jika siapa pun memodifikasi bahkan satu karakter dalam header atau payload setelah token diterbitkan, signature menjadi tidak valid dan verifikasi gagal. Tanpa mengetahui rahasia penandatanganan (atau kunci privat penerbit untuk RS256/ES256), penyerang tidak dapat memalsukan token yang valid.

Referensi Klaim JWT Standar

Mengapa Klaim exp Sangat Kritis

Klaim exp adalah timestamp Unix — jumlah detik sejak 1 Januari 1970 (UTC). Dalam contoh kita, "exp": 1738371600. Untuk mengonversi ini ke tanggal yang dapat dibaca manusia, Anda dapat menggunakan JavaScript:

new Date(1738371600 * 1000).toUTCString()
// → "Sat, 01 Feb 2026 01:00:00 GMT"

Kedaluwarsa JWT adalah hal pertama yang harus diperiksa ketika token ditolak. Token yang valid kemarin akan gagal hari ini jika exp-nya di masa lalu — ini by design. Token berumur pendek (15 menit hingga 1 jam) membatasi jendela kerusakan jika token dicuri. Token berumur lebih lama (hari atau minggu) lebih nyaman tetapi lebih berbahaya jika dikompromikan.

Decoder JWT BrowseryTools secara otomatis membaca klaim exp dan iat dan menampilkannya sebagai tanggal yang dapat dibaca manusia di samping timestamp Unix mentah, sehingga Anda tidak perlu melakukan matematika mental secara manual.

Skenario Debugging JWT Umum

Token Kedaluwarsa (401 Unauthorized)

Kesalahan JWT yang paling umum. Server menolak token karena waktu saat ini melewati nilai exp. Perbaikan: implementasikan alur refresh token menggunakan refresh token berumur lebih panjang, atau cukup autentikasi ulang. Tempel token ke decoder untuk mengonfirmasi kapan tepatnya token kedaluwarsa.

Audiens Salah

Jika API Anda memvalidasi klaim aud dan token diterbitkan untuk audiens yang berbeda (misalnya, token yang diterbitkan untuk https://api-staging.example.com yang dikirim ke https://api.example.com), server akan menolaknya. Dekode token dan periksa kolomaud untuk mengonfirmasi cocok dengan apa yang diharapkan layanan penerima.

Ketidakcocokan Algoritma

Jika server Anda mengharapkan RS256 tetapi menerima token yang ditandatangani dengan HS256 (atau sebaliknya), validasi gagal. Ini bisa terjadi selama rotasi kunci atau ketika beralih penyedia auth. Periksa kolom alg di header yang didekode terhadap apa yang dikonfigurasi server Anda untuk diterima.

Signature Tidak Valid

Jika payload telah dirusak — bahkan satu karakter yang diubah — signature tidak akan cocok. Ini juga terjadi jika Anda menggunakan rahasia yang salah atau kunci publik yang salah untuk memverifikasi. Mendekode header dan payload (yang tidak memerlukan rahasia) memungkinkan Anda setidaknya memeriksa apa yang diklaim token, bahkan jika Anda tidak dapat memverifikasi keasliannya di sisi klien.

JWT vs Token Sesi: Kapan Menggunakan Masing-Masing

JWT dan token sesi tradisional memecahkan masalah yang sama — mengidentifikasi pengguna yang terautentikasi di berbagai permintaan — tetapi mereka melakukannya secara berbeda, dan tidak ada yang secara universal lebih baik.

Token sesi tradisional adalah string acak yang buram (misalnya, UUID) yang disimpan sisi server dalam penyimpanan sesi (Redis, database). Pada setiap permintaan server mencari token dalam penyimpanan dan mengambil data pengguna. Server memiliki kontrol penuh: membatalkan sesi segera mencabut akses.

JWT bersifat stateless. Server menerbitkan token yang ditandatangani dan tidak menyimpan catatan tentangnya. Pada setiap permintaan server memverifikasi signature dan mempercayai klaim tanpa pencarian database apa pun. Ini skalabel secara horizontal tanpa status bersama — server mana pun dengan kunci verifikasi dapat mengautentikasi permintaan. Tradeoff: Anda tidak dapat segera mencabut JWT sebelum kedaluwarsa (kecuali Anda mengimplementasikan daftar blokir token, yang memperkenalkan kembali state).

• Gunakan JWT untuk layanan mikro stateless, sistem terdistribusi, API mobile, dan autentikasi lintas domain (alur OAuth/OIDC). Jaga waktu kedaluwarsa tetap singkat.
• Gunakan token sesi ketika Anda membutuhkan kemampuan pencabutan segera (logout, penangguhan akun, insiden keamanan), atau ketika semua layanan Anda berbagi penyimpanan sesi yang cepat.

Cara Menggunakan Decoder JWT BrowseryTools

Buka Decoder JWT dan tempel token Anda ke kolom input. Alat ini segera memisahkan token pada dua titik dan menampilkan:

• Panel header: JSON yang didekode menampilkan alg, typ, dan kolom header lainnya. Berguna untuk mengidentifikasi algoritma penandatanganan sekilas.
• Panel payload: JSON yang didekode secara lengkap dengan semua klaim. Timestamp ditampilkan dalam format Unix mentah maupun tanggal UTC yang dapat dibaca manusia sehingga Anda dapat segera melihat kedaluwarsa tanpa konversi mental.
• Status kedaluwarsa: Indikator yang jelas menunjukkan apakah token saat ini valid, sudah kedaluwarsa, atau belum aktif (berdasarkan nbf). Jika kedaluwarsa, Anda melihat berapa lama yang lalu token kedaluwarsa.
• Segmen signature: Signature yang dienkode Base64URL mentah, ditampilkan untuk referensi. Alat ini tidak memverifikasi signature (itu memerlukan rahasia atau kunci publik), tetapi mendekode dan menampilkan semua informasi yang Anda butuhkan untuk debugging.

Tidak ada pengiriman formulir, tidak ada permintaan server, tidak ada akses clipboard di luar apa yang Anda tempel secara eksplisit. Parsing token terjadi sepenuhnya dalam JavaScript yang berjalan di tab browser Anda.

Dekode Token JWT Anda Sekarang

Baik Anda men-debug token yang kedaluwarsa, memeriksa klaim dari penyedia OAuth, memeriksa peran apa yang telah diberikan kepada pengguna, atau sekadar mencoba memahami apa yang sebenarnya diterbitkan sistem autentikasi Anda — Decoder JWT BrowseryTools memberi Anda jawabannya secara instan. Tanpa registrasi, tanpa ekstensi yang perlu dipasang, tanpa data yang dikirim ke mana pun.