JWT dijelaskan: struktur, klaim, dan cara mendekodenya

Jika Anda pernah bekerja dengan API web modern, Anda pernah bertemu JWT — deretan panjang tak berarti dengan dua titik yang muncul di respons login dan header Authorization. Tampak buram, tetapi mengejutkan mudah dibaca begitu Anda tahu strukturnya. Panduan ini menjelaskan apa itu JSON Web Token, apa isinya, bagaimana tanda tangan bekerja, dan kesalahan keamanan yang harus dihindari.

Untuk apa JWT

JSON Web Token (JWT) adalah cara ringkas dan mandiri untuk membawa sekumpulan klaim — pernyataan seperti "ini pengguna 42 dan ia masuk pukul 10:05". Kegunaan utamanya adalah autentikasi: setelah login, server menerbitkan JWT, aplikasi Anda mengirimkannya kembali di tiap permintaan, dan server mempercayainya alih-alih mencari Anda di penyimpanan sesi setiap kali. Karena token membawa informasi itu sendiri, ia disebut tanpa keadaan (stateless).

Tiga bagian

Setiap JWT adalah tiga bagian berkode Base64URL yang disambung dengan titik: header.payload.signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.3x9kQ...
└──── header ────┘ └── payload ──┘ └ signature ┘

1. Header

Metadata tentang token — algoritma tanda tangan (alg, mis. HS256) dan tipe (typ: JWT). Setelah didekode, ia hanyalah JSON kecil:

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

2. Payload

Klaim — data sebenarnya. Beberapa nama sudah dibakukan (disebut klaim terdaftar):

• sub — subjek, biasanya ID pengguna.
• iss — penerbit (issuer), siapa yang membuat token.
• aud — audiens (audience), untuk siapa ia ditujukan.
• exp — waktu kedaluwarsa (sebuah timestamp Unix).
• iat — waktu penerbitan (sebuah timestamp Unix).

Nilai exp dan iat itu adalah detik sejak 1970 — jika Anda perlu membacanya sebagai tanggal nyata, konverter timestamp mengubahnya menjadi waktu yang terbaca manusia.

3. Tanda tangan (Signature)

Tanda tangan adalah yang membuat token bisa dipercaya. Penerbit mengambil header dan payload, dan memakai kunci rahasia, menghasilkan tanda tangan kriptografis. Siapa pun yang punya kunci bisa memverifikasi bahwa header dan payload tak diubah — ubah satu karakter saja di payload dan tanda tangan tak lagi cocok.

Hal terpenting untuk dipahami

JWT ditandatangani, bukan dienkripsi. Header dan payload hanya berkode Base64URL, yang berarti siapa pun bisa mendekode dan membacanya — tanpa kunci. Tanda tangan mencegah perusakan, bukan pembacaan.

Konsekuensi praktisnya: jangan pernah menaruh rahasia di payload JWT. Tak ada kata sandi, nomor kartu kredit, atau data pribadi — anggap payload itu publik. Anda bisa membuktikannya sendiri dengan menempel token apa pun ke dekoder JWT kami, yang membaca header dan klaim seketika, sepenuhnya di browser Anda (token tak pernah meninggalkan perangkat). Di baliknya cuma dekode Base64 — dekoder hanya menghemat langkah-langkahnya untuk Anda.

Memverifikasi vs. mendekode

Ini dua tindakan berbeda, dan mengacaukannya adalah bug keamanan yang nyata. Mendekode membaca payload — siapa pun bisa dan itu tak membuktikan apa-apa. Memverifikasi memeriksa tanda tangan dengan kunci dan memastikan token asli dan tak diubah. Server harus memverifikasi setiap token sebelum mempercayainya; mendekode saja bukan autentikasi.

Jebakan umum

• Mempercayai token yang belum diverifikasi — selalu periksa tanda tangan di sisi server sebelum bertindak berdasarkan klaim.
• Mengabaikan kedaluwarsa — hormati exp; token kedaluwarsa harus ditolak.
• Menyimpan data sensitif di payload — ia terbaca oleh siapa pun.
• Jebakan `alg: none` — beberapa pustaka pernah menerima token yang mengklaim "tanpa tanda tangan". Tolak, dan patok algoritma yang diharapkan.

Pahami itu, dan JWT berubah dari deretan yang menakutkan menjadi format sederhana dan transparan: klaim yang terbaca, dilindungi oleh tanda tangan yang harus Anda verifikasi sebelum mempercayai.