Dekoder JWT

Decode JSON Web Token apa pun di browser Anda

JWT decoder ini mengubah string eyJ… yang tidak terbaca menjadi JSON yang jelas dalam sekejap. Tempel JSON Web Token dan tool ini memecahnya di titik-titik, men-decode Base64URL header dan payload, lalu mem-pretty-print keduanya berdampingan, dengan signature mentah ditampilkan terpisah. Ini cara cepat untuk men-debug alur autentikasi, memeriksa token dari respons API, atau memastikan claim apa persis yang diterbitkan backend Anda.

Setiap bagian token diberi warna berbeda — header, payload, dan signature — sehingga ketiga bagian dari header.payload.signature mudah dibedakan sekilas. Tidak ada akun, tidak ada upload server, dan tidak ada batas decode harian.

Baca claim dan cek masa berlaku sekilas

Decoder ini menyorot claim standar yang terdaftar di RFC 7519 — iss, sub, aud, exp, nbf, iat dan jti — dalam tabel yang jelas dengan arti dalam bahasa sederhana untuk masing-masing. Tiga claim timestamp berupa detik Unix epoch, yang mudah salah dibaca, jadi tool ini mengonversinya ke tanggal dan waktu lokal Anda serta menambahkan petunjuk relatif seperti 'diterbitkan 5 menit lalu' atau 'kedaluwarsa dalam 59 menit'.

Yang paling penting, ia menjawab pertanyaan yang biasanya membuat Anda membuka JWT debugger: apakah token ini masih berlaku? Claim exp diperiksa terhadap waktu saat ini dan token ditandai Valid atau Expired, dengan nbf juga dihormati, sehingga Anda langsung tahu apakah token kedaluwarsa adalah penyebab sebuah permintaan ditolak. jwt.io menampilkan timestamp mentah tapi tidak menandai status kedaluwarsa secara otomatis — Anda harus menghitungnya sendiri.

Verifikasi signature — HS256, RS256, dan ES256

Decoding menunjukkan apa isi sebuah token; verifikasi membuktikan apakah Anda bisa mempercayainya. Tool ini juga merupakan JWT signature verifier: ia membaca algoritma dari header dan memverifikasi signature secara lokal dengan Web Crypto API milik browser. Untuk HS256, HS384 dan HS512 Anda memasukkan shared secret HMAC; untuk RS256, PS256 dan ES256 (serta varian 384/512-nya) Anda menempel public key penerbit dalam format PEM.

Karena perhitungannya berjalan di perangkat Anda, Anda bisa memastikan sebuah token asli — bahwa tidak ada yang mengubah payload-nya — tanpa mengirim token, secret, atau key ke server mana pun. Tanda centang hijau berarti signature cocok; tanda silang merah berarti token diubah atau Anda memakai key yang salah. jwt.io membutuhkan upgrade akun untuk memverifikasi token RS256 dengan public key kustom; tool ini melakukannya gratis, selalu.

Buat dan encode JWT juga

Butuh arah sebaliknya? JWT encoder bawaan memungkinkan Anda merancang token dari awal. Edit header dan payload sebagai JSON, pilih algoritma HMAC, masukkan secret, dan tool ini menghasilkan token header.payload.signature yang ditandatangani dengan benar dan siap disalin ke sebuah permintaan atau tes. Shortcut praktis menyisipkan claim iat dan exp segar sehingga token uji Anda punya timestamp yang realistis.

Itu menjadikan UtiloKit JWT decoder dan encoder gabungan — memeriksa token yang datang kembali dari API Anda dan membuat yang baru untuk dikirim, semuanya di tempat yang sama. Ini alur kerja yang sama yang dipakai developer dengan jwt.io, tapi tanpa keterlibatan server dan tanpa akun yang dibutuhkan.

Bagaimana ini dibandingkan dengan jwt.io, token.dev, dan jwtdecode.com

jwt.io adalah tool JWT paling dikenal di web — dibuat oleh Auth0, banyak ditautkan di dokumentasi, dan dipercaya jutaan developer. Batasan utamanya adalah privasi: jwt.io mengirim token Anda ke server Auth0 dalam beberapa konfigurasi, dan terintegrasi dengan produk komersial Auth0. Jika Anda men-debug token dari sistem autentikasi kompetitor atau API internal rahasia, itu jadi masalah.

token.dev dan jwtdecode.com mencakup decoding dasar tapi tidak mendukung verifikasi signature RS256/ES256 dengan PEM key, yaitu algoritma yang dipakai Auth0, Google, Microsoft Azure AD, Okta, dan sebagian besar penyedia OIDC enterprise. Anda akhirnya harus menyalin public key dari endpoint JWKS penyedia dan memverifikasinya secara manual di kode.

Decoder UtiloKit ini menangani semua itu di browser: decoding, cek kedaluwarsa, dan verifikasi signature penuh di seluruh keluarga algoritma HS/RS/PS/ES — gratis, tanpa akun, tanpa batas harian, dan tanpa apa pun yang meninggalkan perangkat Anda. Ini tool yang tepat untuk pekerjaan debugging autentikasi harian.

Keamanan JWT: apa yang bisa dan tidak bisa dilindungi token

JWT ditandatangani untuk integritas, bukan dienkripsi untuk kerahasiaan. Siapa pun yang memegang token bisa membaca setiap claim dalam payload — encoding Base64URL-nya bisa dibalik dengan mudah, seperti yang ditunjukkan decoder ini. Jadi payload seharusnya hanya berisi pengenal yang tidak sensitif: user ID, role, atau email. Jangan pernah menaruh password, detail pembayaran, atau API key dalam payload JWT.

Signature melindungi dari perubahan: jika penyerang mengubah bahkan satu karakter dari payload, signature tidak akan cocok lagi dan server mana pun yang memverifikasi dengan key yang benar akan menolak token tersebut. Serangan klasik alg: none membobol ini dengan mengklaim tidak ada algoritma yang dipakai — kerentanan yang sudah dikenal (CVE-2015-9235) yang seharusnya diblokir oleh pustaka JWT produksi mana pun. Tool ini menandai token none dan menolak menyebutnya valid.

Jaga masa berlaku token tetap singkat memakai exp, kirim lewat HTTPS, simpan di memori atau cookie httpOnly (bukan localStorage), dan verifikasi signature pada setiap permintaan. Decode dan periksa token Anda dengan tool gratis ini untuk memastikan properti tersebut ditetapkan dengan benar sebelum deploy ke produksi.

Spesifikasi JWT: RFC 7519 dan cara kerja tiga bagiannya

RFC 7519, dipublikasikan tahun 2015 oleh IETF, adalah spesifikasi normatif untuk JSON Web Token. Ia mendefinisikan sebuah token sebagai tiga segmen berenkoding Base64URL yang dipisahkan titik — header.payload.signature — di mana Base64URL adalah varian Base64 yang aman untuk URL yang mengganti + dengan -, / dengan _, dan menghapus padding karakter = sehingga token bisa disematkan dalam query string URL tanpa encoding tambahan. Header adalah objek JSON yang mendeklarasikan tipe token (typ: "JWT") dan algoritma penandatanganan (alg): algoritma simetris seperti HS256 (HMAC-SHA-256) atau asimetris seperti RS256 (RSA-SHA-256) atau ES256 (ECDSA-P256).

Payload membawa claim — pernyataan tentang subjek. RFC 7519 membedakan tiga kategori. Registered claims adalah tujuh field standar: iss (issuer — siapa yang membuat token), sub (subject — biasanya user ID), aud (audience — layanan penerima yang dituju), exp (expiration — timestamp Unix setelah mana token harus ditolak), nbf (not-before — token tidak valid sebelum waktu ini), iat (issued-at — kapan token dibuat), dan jti (ID token unik untuk pencegahan replay). Public claims adalah nama yang terdaftar di IANA JSON Web Token Claims Registry untuk menghindari tabrakan. Private claims adalah field khusus aplikasi kustom — role, tenant ID, tier paket, atau data lain apa pun yang dibutuhkan sistem Anda — yang disepakati antara penerbit dan konsumen.

Signature dihitung dari string ASCII base64url(header) + '.' + base64url(payload). Untuk HS256, server melakukan hash string tersebut dengan shared secret memakai HMAC-SHA-256. Untuk RS256, server menandatanganinya dengan private key RSA, dan pihak mana pun yang memegang public key yang sesuai bisa memverifikasi signature tanpa mengetahui private key-nya. Asimetri inilah yang membuat RS256 cocok untuk identitas federasi: penyedia identitas (IdP) menandatangani token dengan private key-nya, dan setiap API dalam organisasi bisa memverifikasinya dengan public key yang dipublikasikan — tanpa perlu distribusi secret.

Kerentanan alg:none — mengapa Anda tidak boleh pernah memercayai header

Pada 2015 peneliti keamanan Tim McLean mengungkap cacat kritis yang memengaruhi banyak pustaka JWT: banyak implementasi membaca field alg dari header token untuk memutuskan cara memverifikasi signature. Penyerang bisa merancang token dengan "alg": "none" di header, menghapus signature sepenuhnya, mengubah payload untuk menaikkan role mereka menjadi admin, dan meng-encode ulang header serta payload. Pustaka yang menghormati nilai alg: none akan melewati verifikasi signature — menyelesaikan langkah verifikasi dengan hasil sukses meski tidak ada signature yang hadir. Ini dikatalogkan sebagai CVE-2015-9235 dan memengaruhi pustaka JWT Node.js, Python, PHP, Ruby, dan Java dari era itu.

Varian serangan terkait menargetkan kebingungan algoritma antara RS256 dan HS256. Jika server mengharapkan RS256 (asimetris, memverifikasi dengan public key) tapi penyerang mengirim token dengan alg: HS256, beberapa pustaka beralih ke verifikasi simetris — memakai public key sebagai secret HMAC. Karena public key, secara definisi, diketahui publik, penyerang bisa menandatangani sendiri token palsu tersebut dan server akan memverifikasinya sebagai asli. Pelajaran intinya sama: algoritma yang dipakai untuk verifikasi harus ditetapkan di sisi server, bukan dibaca dari header token yang tidak dipercaya.

Pustaka JWT modern yang terpelihara dengan baik (python-jose, jsonwebtoken ≥ 9, java-jwt, nimbus-jose-jwt) mengharuskan pemanggil menentukan algoritma yang diharapkan secara eksplisit dan akan melempar error jika alg token berbeda. Opsi alg: none dinonaktifkan secara default dan harus diaktifkan secara sengaja dengan sebuah flag — perubahan signifikan dari desain pustaka awal. Saat meninjau implementasi JWT, selalu pastikan bahwa parameter algorithms (atau yang setara) di-hardcode dan tidak diturunkan dari header token yang masuk. Decoder ini menandai token alg: none sebagai tidak terverifikasi untuk membuat risikonya terlihat saat debugging.

JWT vs session cookie — token stateless dan masalah revokasi

Autentikasi web tradisional memakai session cookie: server menghasilkan session ID acak, menyimpan state sesi (user ID, role, preferensi) dalam database atau cache seperti Redis, dan mengirim hanya session ID ke browser sebagai cookie. Setiap permintaan berikutnya membuat server mencari session ID tersebut di penyimpanan untuk mengambil state pengguna. Model ini stateful: server memegang kebenaran. Invalidasi bersifat instan — hapus record sesi dan cookie tersebut menjadi tidak berguna pada permintaan berikutnya. Kekurangannya adalah skalabilitas: setiap permintaan membutuhkan round-trip database, dan server yang di-scale secara horizontal butuh penyimpanan sesi bersama agar node mana pun bisa mencari sesi mana pun.

JWT bersifat stateless: token ITU-lah sesinya. Server menyematkan identitas dan izin pengguna langsung ke dalam payload yang ditandatangani secara kriptografis dan mengirimkannya ke klien. Pada permintaan berikutnya klien mengirim token kembali, dan server mana pun yang tahu signing key (atau public key untuk RS256) bisa memverifikasi dan membacanya tanpa menyentuh database. Ini berarti armada microservice bisa memvalidasi token secara independen tanpa lookup auth terpusat — ideal untuk arsitektur terdistribusi. Scaling horizontal jadi trivial karena tidak ada state bersama yang perlu disinkronkan.

Harga dari statelessness adalah masalah revokasi. JWT valid sampai timestamp exp-nya terlepas dari apa yang terjadi di server. Jika pengguna logout, token mereka tetap valid. Jika akun admin diretas dan pengguna dinonaktifkan di database, JWT mereka tetap mengautentikasi permintaan sampai kedaluwarsa. Mitigasi umum meliputi menjaga masa berlaku access token tetap singkat (15 menit adalah default yang umum) dipasangkan dengan refresh token berumur lebih panjang yang disimpan di sisi server dan bisa direvokasi, menambahkan claim generation atau tokenVersion ke JWT dan memeriksanya terhadap database pada setiap permintaan (yang memunculkan kembali panggilan database tapi hanya untuk satu skalar itu), atau memelihara daftar blokir token untuk operasi berisiko tinggi seperti reset password dan pencabutan hak akses. Untuk sebagian besar aplikasi konsumen, JWT berumur pendek dengan rotasi refresh token memberikan keseimbangan yang tepat.

OAuth 2.0, OpenID Connect, dan peran JWT dalam identitas modern

OAuth 2.0 (RFC 6749) adalah kerangka otorisasi — ia mendefinisikan bagaimana pengguna memberikan akses terbatas ke data mereka di layanan lain kepada aplikasi pihak ketiga, tapi tidak mengatakan apa pun tentang format token. Access token OAuth bisa berupa string acak opaque atau JWT; itu terserah server otorisasi. OpenID Connect (OIDC) adalah lapisan autentikasi yang dibangun di atas OAuth 2.0 yang memang mewajibkan JWT: id_token. ID token berisi claim OIDC yang terdaftar (sub, iss, aud, iat, exp, nonce) dan di-decode oleh aplikasi klien untuk mengetahui siapa yang terautentikasi — identitas pengguna. Access token dikirim ke API resource untuk mengotorisasi aksi; ID token dikonsumsi oleh relying party untuk menetapkan identitas. Mencampuradukkan keduanya (mengirim ID token ke API, atau men-decode access token dengan mengharapkan data profil pengguna) adalah sumber bug autentikasi halus yang umum.

Semua penyedia identitas utama memakai OIDC dan menerbitkan JWT RS256 atau ES256: Google Identity, Microsoft Azure AD, Auth0, Okta, Keycloak, AWS Cognito, Firebase Authentication, dan Supabase Auth. Masing-masing mempublikasikan endpoint JWKS (JSON Web Key Set) — URL publik yang mengembalikan kumpulan public key saat ini dalam format JSON standar. Header JWT membawa claim kid (Key ID) yang mengidentifikasi key mana dalam JWKS yang dipakai untuk menandatangani token. Layanan yang melakukan verifikasi mengambil JWKS, mencari key yang cocok berdasarkan kid, dan memverifikasi signature. Mekanisme rotasi key ini memungkinkan penyedia memutar signing key mereka tanpa membatalkan semua token yang beredar — key lama tetap ada di JWKS sampai token yang ada kedaluwarsa, dan token baru ditandatangani dengan key baru.

OAuth 2.0 mendefinisikan beberapa alur grant untuk kasus pemakaian berbeda. Authorization Code Flow dipakai oleh aplikasi web sisi server — server menukar kode berumur pendek dengan token, menjaga access token tetap di luar browser. Authorization Code dengan PKCE (Proof Key for Code Exchange, RFC 7636) memperluas ini ke aplikasi single-page dan mobile, menambahkan tantangan-respons kriptografis untuk mencegah serangan interception authorization code; OAuth 2.1 mewajibkan PKCE untuk semua klien publik. Client Credentials Flow untuk autentikasi mesin-ke-mesin — sebuah layanan mengautentikasi langsung dengan client ID dan secret dan menerima access token yang di-scope ke izin tingkat layanan, tanpa pengguna terlibat. Memahami alur mana yang menerbitkan sebuah token — dan karenanya claim mana yang diharapkan — adalah konteks penting saat men-decode dan men-debug JWT dari berbagai bagian sistem.