Dekoder JWT

Tempel token JWT apa pun dan langsung lihat header dan payload yang telah didekode sebagai JSON berformat.

Dekoder kami:

• mengidentifikasi algoritma penandatanganan
• menampilkan semua klaim standar dan kustom
• mengubah stempel waktu Unix menjadi tanggal yang mudah dibaca manusia

Tampilan berkode warna memudahkan Anda membedakan ketiga bagian JWT.

Debug masalah JWT dengan memeriksa waktu kedaluwarsa, stempel waktu penerbitan, dan nilai klaim.

Alat kami menunjukkan apakah token telah kedaluwarsa, berapa lama waktu hingga kedaluwarsa, dan menyoroti potensi masalah.

Penting untuk:

• pengembangan API
• debugging otentikasi
• audit keamanan

Sebuah JSON Web Token (JWT) adalah cara yang ringkas dan aman untuk URL untuk merepresentasikan klaim yang ditransfer antara dua pihak, yang ditentukan oleh RFC 7519 dari IETF.

Sebuah JWT memiliki tiga bagian yang dipisahkan oleh titik, masing-masing dikodekan dengan Base64URL sesuai RFC 4648:

• header yang mendeklarasikan algoritma penandatanganan dan jenis token menggunakan JSON (RFC 8259)
• payload yang membawa klaim — pernyataan tentang suatu entitas seperti pengguna, ditambah metadata seperti kedaluwarsa
• tanda tangan yang mengikat header dan payload bersama-sama sehingga manipulasi dapat terdeteksi

Struktur ini memungkinkan layanan memverifikasi identitas tanpa pencarian basis data, itulah sebabnya JWT umum digunakan dalam otentikasi tanpa status dan alur OpenID Connect.

Untuk mendekode JWT, bagi token pada kedua titiknya menjadi tiga segmen, lalu dekode Base64URL pada dua segmen pertama.

Segmen pertama menghasilkan JSON header, dan yang kedua menghasilkan JSON payload, keduanya dapat dibaca sebagai teks biasa menurut RFC 8259.

Base64URL (RFC 4648, bagian 5) menggantikan '+' dengan '-' dan '/' dengan '_' serta menghilangkan padding, sehingga dekoder Base64 standar mungkin gagal tanpa penyesuaian. Alat kami menangani hal ini secara otomatis dan mencetak hasilnya dengan rapi.

Segmen ketiga, tanda tangan, tidak didekode ke teks karena merupakan nilai kriptografi mentah.

Sebagaimana dicatat oleh MDN Web Docs, mendekode bukan berarti memverifikasi — membaca payload tidak pernah mengonfirmasi bahwa token tersebut otentik.

Tidak — JWT bertandatangan standar (JWS) adalah dikodekan, bukan dienkripsi, sehingga siapa pun yang memegang token dapat membaca payload-nya.

Pengodean Base64URL (RFC 4648) dapat dibalik dan tidak memberikan kerahasiaan sama sekali; pengodean ini hanya memungkinkan pengiriman yang aman untuk biner. Tanda tangan yang dijelaskan dalam RFC 7515 (JSON Web Signature) melindungi integritas dan keaslian, bukan kerahasiaan.

Jika Anda perlu menyembunyikan isinya, gunakan JWE (JSON Web Encryption, RFC 7516).

OWASP dan IETF sama-sama menekankan perbedaan ini: jangan pernah menempatkan kata sandi, rahasia API, atau data pengenal pribadi dalam payload JWT yang ditandatangani, karena dekoder seperti ini mengungkapkan setiap klaim dalam teks biasa tanpa kunci apa pun.

Klaim JWT terdaftar distandarisasi oleh RFC 7519 agar sistem yang berbeda dapat menafsirkannya secara konsisten.

Inti rangkaian klaim meliputi:

• 'iss' (penerbit)
• 'sub' (subjek, prinsipal token)
• 'aud' (audiens, penerima yang dituju)
• 'exp' (waktu kedaluwarsa)
• 'nbf' (tidak berlaku sebelum)
• 'iat' (diterbitkan pada)
• 'jti' (ID token unik)

Nilai exp, nbf, daniat adalah nilai NumericDate — detik sejak zaman Unix — yang diubah oleh dekoder kami menjadi tanggal yang mudah dibaca manusia. Aplikasi menambahkan klaim kustom (privat) untuk peran, cakupan, atau ID penyewa.

Berdasarkan spesifikasi, verifikator harus menolak token yang 'exp'-nya telah terlewati atau 'aud'-nya tidak cocok dengan audiens yang diharapkan, untuk mencegah penyalahgunaan di berbagai layanan.

Algoritma penandatanganan JWT ditentukan dalam RFC 7518 (JSON Web Algorithms) dan diidentifikasi oleh nilai 'alg' pada header.

• Algoritma HMAC (HS256, HS384, HS512) menggunakan satu rahasia bersama untuk penandatanganan dan verifikasi, yang sederhana tetapi mengharuskan setiap verifikator memegang rahasia tersebut.
• Algoritma RSA (RS256, RS384, RS512) dan RSASSA-PSS (PS256) menggunakan kunci privat untuk menandatangani dan kunci publik untuk memverifikasi, ideal untuk sistem terdistribusi dan OpenID Connect.
• Algoritma ECDSA (ES256, ES384, ES512) menawarkan keamanan yang setara dengan kunci dan tanda tangan yang lebih kecil.

NIST menerbitkan standar SHA-2 dan ECDSA yang mendasarinya. Dekoder kami membaca bidang 'alg' sehingga Anda dapat mengonfirmasi skema mana yang digunakan oleh token.

JWT banyak digunakan untuk otentikasi tanpa status (stateless), otorisasi, dan pertukaran informasi yang aman pada API modern.

Setelah pengguna masuk, server menerbitkan JWT bertanda tangan yang dikembalikan oleh klien dalam header HTTP Authorization sebagai token Bearer, sesuai RFC 6750. Karena tanda tangannya bersifat mandiri (self-contained), layanan backend dapat memverifikasi token tanpa perlu mengkueri penyimpanan sesi, sehingga meningkatkan skalabilitas.

JWT juga mendukung token ID OpenID Connect dan pola token akses OAuth 2.0.

Pengembang menggunakan decoder saat proses debug untuk memeriksa klaim, mengonfirmasi nilai audiens dan penerbit, serta memeriksa masa kedaluwarsa saat API mengembalikan error 401. Sebagaimana dijelaskan oleh MDN Web Docs, alur berbasis token ini menjadi fondasi bagi banyak arsitektur single-sign-on dan layanan mikro.

Penggunaan JWT yang aman berpusat pada validasi algoritma, verifikasi tanda tangan, dan penegakan masa kedaluwarsa.

OWASP memperingatkan agar mewaspadai serangan 'alg: none' klasik dan serangan kebingungan algoritma (algorithm-confusion), di mana server yang terkecoh menganggap kunci publik RS256 sebagai rahasia HMAC dapat dipalsukan; selalu tetapkan algoritma yang diharapkan alih-alih mempercayai header.

Praktik utama:

• Gunakan masa 'exp' yang singkat dengan token pembaruan (refresh token), serta validasi 'iss' dan 'aud' pada setiap permintaan.
• Jangan pernah menyimpan data rahasia di dalam payload, karena hanya dikodekan dengan Base64.
• Transmisikan token secara eksklusif melalui HTTPS, dan pertimbangkan strategi pencabutan karena JWT standar tidak dapat dibatalkan satu per satu sebelum kedaluwarsa.

Mengikuti rekomendasi IETF dan OWASP ini akan menutup kerentanan JWT yang paling sering dieksploitasi.

Kesalahan paling umum saat bekerja dengan JWT meliputi:

• Mencampuradukkan proses decoding dengan verifikasi: membaca payload dengan decoder sama sekali tidak membuktikan keaslian, karena siapa pun dapat membuat token yang tidak ditandatangani atau dipalsukan.
• Mempercayai nilai 'alg' pada header secara membabi buta, yang membuka celah serangan kebingungan algoritma yang ditandai oleh OWASP.
• Salah membaca masa kedaluwarsa dengan membandingkan 'exp' dalam satuan detik epoch terhadap milidetik, yang membuat token valid tampak kedaluwarsa.
• Menggunakan decoder Base64 standar alih-alih Base64URL (RFC 4648), yang dapat merusak output karena perbedaan alfabet dan padding yang hilang.
• Menempatkan data sensitif di dalam payload, yang menyebabkan kebocoran, karena token hanya dikodekan, bukan dienkripsi.

Memverifikasi tanda tangan di sisi server dengan kunci dan algoritma yang tepat akan menghindari kendala-kendala ini.

Decoder JWT ini memproses token sepenuhnya di sisi klien, sehingga token Anda tidak pernah meninggalkan perangkat atau menjangkau server mana pun.

Karena JWT yang ditandatangani hanya dikodekan dengan Base64URL (RFC 4648), proses decoding tidak memerlukan panggilan jaringan — header dan payload cukup dikembalikan dari bentuk kodenya menggunakan JavaScript di peramban Anda.

Menjaga operasi tetap lokal sangat penting untuk keamanan: token sering kali berisi kredensial sesi aktif, dan menempelkannya ke alat berbasis server dapat mengeksposnya dalam log atau transmisi. OWASP menyarankan untuk meminimalkan jalur perjalanan kredensial yang bersifat sensitif.

Decoder khusus peramban memungkinkan pengembang memeriksa token produksi dengan aman saat melakukan debug sembari tetap mematuhi prinsip paparan minimum (least-exposure), tanpa mentransmisikan data otorisasi ke pihak ketiga.