JWT (JSON Web Token) adalah standar terbuka yang didefinisikan oleh IETF dalam RFC 7519 (RFC 7515 menjelaskan format tanda tangan JWS, RFC 7516 menjelaskan enkripsi JWE, RFC 7517 mendefinisikan kunci JWK) untuk mentransfer informasi pengguna 'yang dideklarasikan' dengan aman antara permintaan HTTP, alur OIDC, dan panggilan layanan mikro. String JWT standar terdiri dari tiga segmen yang dienkode Base64URL: Header (algoritma dan jenis), Payload (Claims, data pengguna), dan Signature (tanda tangan berbasis kunci atas dua segmen pertama). Tiga segmen digabungkan dengan titik `.`, contoh `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT bukan enkripsi.** Ini adalah kesalahpahaman paling umum. Payload secara default adalah teks polos — siapa pun dapat mendekode Base64URL dan membaca isinya. JWT menyediakan **deteksi perubahan**, bukan kerahasiaan: server menandatangani ulang Header.Payload dengan kunci bersama dan membandingkan dengan Signature token. Jika cocok, token tidak diubah selama transit. Ini adalah metafora 'tiket kereta dengan stempel anti-pemalsuan': inspektur peduli apakah tiket asli, bukan apakah kode QR dapat dibaca.
JWT membagi tanggung jawab dengan jelas di antara 13 algoritma. **Keluarga HMAC** (HS256/HS384/HS512) menggunakan kunci simetris untuk penandatanganan dan verifikasi, cepat dan sederhana, cocok untuk satu layanan atau kluster tepercaya; secret harus setidaknya sepanjang digest (contoh: ≥ 32 byte untuk HS256). **Keluarga RSA** (RS256/RS384/RS512) menggunakan RSASSA-PKCS1-v1_5, skema asimetris paling umum — penandatangan memiliki kunci pribadi, verifier memiliki kunci publik. **Keluarga RSA-PSS** (PS256/PS384/PS512) menggunakan padding RSA-PSS yang lebih baru dengan jaminan keamanan yang lebih kuat, disukai oleh AWS SigV4 dan penyedia identitas OIDC modern. **Keluarga ECDSA** (ES256/ES384/ES512) menggunakan kurva eliptik (P-256/P-384/P-521 masing-masing) dengan tanda tangan yang lebih pendek dan kinerja yang lebih baik. **EdDSA** (terutama Ed25519) sangat cepat dan deterministik (pesan yang sama + kunci yang sama = tanda tangan yang sama setiap saat) dan merupakan algoritma yang direkomendasikan dalam OAuth 2.1 dan protokol baru.
Keamanan adalah tempat JWT tersandung dalam produksi. OWASP JWT Cheat Sheet mencantumkan setidaknya empat aturan keras: (1) jangan pernah menempatkan kata sandi, dokumen identitas nasional, nomor kartu, atau kunci API sebagai teks polos di Payload; (2) server harus **tidak pernah mempercayai field alg** yang dideklarasikan di Header Token — harus memverifikasi dengan algoritma yang di-hardcode, jika tidak penyerang yang menulis ulang header menjadi `alg: none` melewati semuanya (ini adalah sumber CVE historis seperti CVE-2015-9235); (3) secret HMAC harus acak dan setidaknya 32 byte, tidak pernah string pendek; (4) verifikasi lebih dari sekadar pemeriksaan tanda tangan — Anda juga harus memvalidasi `exp` (kedaluwarsa), `nbf` (not-before), `iss` (penerbit), dan `aud` (audiens). Alat ini menyoroti masing-masing Claims ini di UI sehingga Anda dapat langsung mengetahui apakah kegagalan adalah masalah tanda tangan, masalah waktu, atau masalah Claims.
JWT bukan pengganti sesi. Sesi menyimpan status pengguna di server (Redis atau database); JWT mengemas status ke dalam token. Arsitektur layanan mikro, API tanpa status, klien seluler, dan pengaturan dengan banyak CORS mendapat manfaat dari JWT; sistem perusahaan tradisional dan alur yang memerlukan pencabutan segera (contoh: 'keluarkan pengguna ini sekarang') masih lebih baik dilayani oleh sesi. Alat ini mencakup debugging JWT murni serta langkah-langkah parsing Token / verifikasi tanda tangan / editing Payload dari migrasi sesi ke JWT.