JWT Hanya Base64 di Dalam Mantel — Dekode Secara Online dalam Detik

Anda sedang memandang tab jaringan. Ada header permintaan yang menyatakan Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c dan reaksi pertama Anda adalah: "Apa ini bahkan?"

Berita baik: sebagian besar dari string tersebut hanyalah Base64. Blok yang terlihat menakutkan itu memakai mantel, berpura-pura lebih misterius daripada yang sebenarnya. Mari kita lepas mantelnya.

Apa Sebenarnya JWT

Token JSON Web adalah tiga bagian yang dienkripsi dengan Base64url dan disambungkan dengan tanda titik:

• Judul – algoritma dan tipe token (misalnya {"alg":"HS256","typ":"JWT"})
• Muatan – klaim: ID pengguna, peran, masa berlaku, apa pun yang ditentukan oleh server untuk dimasukkan
• Tanda tangan – bagian yang sebenarnya mengenalkan keamanan

Header dan payload adalah tidak dienkripsi. Mereka dienkripsi dengan Base64url, yang berarti siapa pun yang memiliki token dapat membaca mereka — tidak perlu kunci. Hanya tanda tangan yang mencegah penyusupan: mengubah satu karakter dalam payload akan menghancurkan token tersebut.

Untuk mendekode payload saat ini: ambil bagian kedua (antara dua tanda titik), tempelkan ke dalam dekode Base64, dan Anda akan melihat JSON biasa. Itu saja. Itu adalah trik ajaib.

Cara Mendekode JWT dalam Detik

Cara tercepat: tempelkan token Anda ke dalam dekode JWT di IOTools. Ini membagi tiga bagian, mendekode masing-masing, dan menampilkan header dan payload sebagai JSON terformat — tanpa akun, tanpa pengaturan, tanpa “masuk untuk membuka dekoder.”

Yang Anda lihat segera dalam payload biasa:

• sub – subjek (biasanya ID pengguna)
• iat – timestamp saat dikeluarkan (epoch Unix)
• exp – timestamp masa berlaku
• iss – penerbit
• Klaim kustom yang dimasukkan oleh API Anda: peran, izin, tingkat rencana, dll.

Jika Anda hanya perlu tahu apakah token telah kedaluwarsa tanpa mengatur dekoder penuh, maka pengecek masa berlaku JWT membaca exp klaim dan memberi tahu Anda secara tepat berapa banyak waktu yang tersisa — atau kapan ia mati.

Tiga Hal yang Menyebabkan Pengembang Terbakar

1. Masa Berlaku yang Ditinggalkan

Itu exp field hanya merupakan angka dalam payload — server seharusnya memvalidasikannya, tetapi banyak kode lama tidak melakukannya, atau memiliki bug dalam pengelolaan zona waktu. Jika pengguna secara misterius keluar dari sistem (atau secara misterius tetap masuk selamanya), dekode token dan lihat exp dibandingkan dengan timestamp Unix saat ini. Pengecek masa berlaku melakukan ini dalam satu klik. melakukannya dalam satu klik.

2. Kebingungan Algoritma

Bidang header alg menginformasikan verifikator algoritma yang harus digunakan. Beberapa library JWT lama akan menerima {"alg":"none"} dan melewatkan verifikasi secara utuh — menghilangkan tanda tangan dan menganggap semua payload sebagai valid. Ini adalah serangan yang dikenal. Selalu verifikasi bahwa library Anda mengizinkan daftar algoritma tertentu dan menolak none.

Variasi lain: RS256 (asimetris) vs HS256 (simetris). Seorang penyerang yang tahu kunci publik Anda dapat membuat token dengan mengganti header menjadi HS256 dan menandatangani dengan kunci publik sebagai rahasia — jika library itu secara naif percaya pada klaim alg di header. Solusi: konfigurasi library Anda dengan algoritma eksplisit, bukan "apa pun yang ditulis dalam token."

3. Kunci dalam Payload

Karena payload dienkripsi dengan Base64 dan tidak dienkripsi, apa pun yang Anda letakkan di dalamnya dapat dibaca oleh klien (dan oleh siapa pun yang mengintersepsi token melalui HTTP biasa, meskipun Anda menggunakan HTTPS di mana-mana, kan?). Jangan letakkan kata sandi, data pribadi, atau detail sistem internal dalam klaim JWT. Payload digunakan untuk metadata otorisasi — bukan tempat menyimpan data sensitif.

Dekode token dari aplikasi Anda sendiri dan lihat apa yang ada di dalamnya. Anda mungkin terkejut dengan apa yang dimasukkan oleh pengembang sebelumnya.

JWT vs Token Session: Apa yang Sebenarnya Berbeda

Debat yang sering muncul. Berikut adalah perbandingan langsung:

	JWT	Token Session
Di mana state berada	Di dalam token (stateless)	Di sisi server (database atau memori)
Penghapusan	Sulit — token berlaku hingga exp kecuali Anda mempertahankan daftar blokir	Mudah — hapus catatan sesi
Skalabilitas	Cocok untuk sistem terdistribusi; tidak perlu penyimpanan sesi bersama	Membutuhkan sesi tetap atau penyimpanan bersama (Redis, dll.)
Kemampuan membaca payload	Klien dapat membaca klaim (tidak dienkripsi)	Opaquen kepada klien
Risiko penyimpanan	localStorage rentan terhadap XSS; cookie httpOnly lebih aman	cookie httpOnly (pendekatan standar)
Ukuran token	Lebih besar — membawa semua klaim secara langsung	Kecil — hanya ID
Cocok untuk	API, microservices, autentikasi lintas domain	Aplikasi web berbasis server

Tidak ada yang lebih baik secara umum. JWT menonjol saat Anda membutuhkan autentikasi tanpa state di antara berbagai layanan. Token sesi lebih sederhana saat Anda mengontrol seluruh stack dan membutuhkan penghapusan instan (misalnya, "keluar dari semua tempat" dalam kejadian keamanan).

Mendekode JWT dalam Alur Kerja Nyata

Berikut adalah urutan umum ketika sesuatu gagal dalam API yang menggunakan JWT:

1. Salin token dari permintaan yang gagal (header Authorization, parameter query, atau cookie — di mana API menempatkan token tersebut)
2. Tempelkan ke dalam dekode JWT untuk melihat klaim mentah
3. Cek exp — apakah token telah kedaluwarsa? Gunakan melakukan ini dalam satu klik. jika Anda tidak ingin melakukan perhitungan timestamp Unix secara manual di kepala Anda
4. Cek iss dan aud — apakah penerbit dan audiens sesuai dengan apa yang diharapkan oleh layanan Anda?
5. Periksa algoritma di header — apakah sesuai dengan konfigurasi server Anda?
6. Periksa format tanda tangan — tiga bagian? Dua? Token yang dimodifikasi kadang menunjukkan dua bagian tanpa tanda tangan

Sebagian besar debugging JWT berakhir pada langkah ke-3. Token dikeluarkan dengan TTL pendek, disimpan di suatu tempat, dan tiba saat sudah kedaluwarsa. Ini adalah hal yang membosankan dan umum.

Tanda Tangan: Bagian yang Paling Penting

Tanda tangan dihitung sebagai: HMACSHA256(base64url(header) + "." + base64url(payload), secret). Server menghasilkannya saat mengeluarkan token. Saat memverifikasi, ia menghitung hash yang sama dan membandingkannya. Jika payload telah diubah secara apa pun — bahkan satu karakter — hash tidak akan cocok dan token ditolak.

Ini yang membuat membaca klaim dari JWT aman dan sederhana, tetapi membuatnya tanpa rahasia tidak mungkin. Base64 adalah kostum; tanda tangan adalah kunci pintu.

Untuk algoritma asimetris (RS256, ES256), kunci penandatangan adalah kunci pribadi yang tidak pernah meninggalkan server autentikasi. Kunci verifikasi adalah kunci publik yang dapat digunakan oleh setiap layanan — tidak perlu kunci bersama. Ini adalah arsitektur yang tepat untuk microservices di mana beberapa layanan perlu memverifikasi token tetapi hanya satu yang harus mengeluarkan token tersebut.

Anda mungkin juga menyukai