Token JWT Dekode, Verifikasi, dan Hindari Kesalahan Umum

Token JWT muncul di hampir setiap aplikasi web modern — header otentikasi, alur pembaruan, pengendalian akses API. Mereka juga merupakan salah satu standar yang paling sering digunakan secara salah di dunia nyata. Jika Anda membangun dengan menggunakan token JWT, memahami apa yang ada di dalam token, apa arti dekoding versus verifikasi, serta mana saja singkatan yang secara diam-diam mengganggu keamanan Anda adalah hal yang mutlak.

Anatomi Token JWT

Sebuah token JWT terdiri dari tiga string berbasis base64url yang dihubungkan dengan tanda titik:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20iLCJpYXQiOjE3MTI3NjQ4MDAsImV4cCI6MTcxMjg1MTIwMH0.4Xr8mNkZQWpH2TvL9uY3sKdJwFqBzEcAoMnRiVePxlU

• Judul — algoritma dan tipe token (alg, typ)
• Muatan — klaim (data yang benar-benar dibutuhkan oleh aplikasi Anda)
• Tanda tangan — tanda tangan HMAC atau RSA atas dua bagian pertama

Setelah didekodifikasi, bagian payload tampak seperti ini:

{
  "sub": "user_123",
  "email": "alice@example.com",
  "iat": 1712764800,
  "exp": 1712851200
}

Tidak ada yang dienkripsi di sini. Siapa pun yang memegang token dapat membaca nilai-nilai ini. Tanda tangan hanya membuktikan bahwa token tidak dimodifikasi setelah dikeluarkan — tidak menyembunyikan isi kontennya.

Dekoding Bukan Verifikasi

Perbedaan ini menyesatkan lebih banyak pengembang daripada yang seharusnya.

Dekoding membagi token di titik-titik dan melakukan dekoding base64url pada setiap bagian. Tidak perlu rahasia — setiap alat atau satu baris kode dapat melakukannya. Jika Anda ingin mendekode token JWT secara online tanpa menginstal sesuatu, tempel token tersebut ke IO Tools Decoder JWT dan dapatkan langsung pembagian header, payload, dan batas waktu kedaluwarsa.

Verifikasi memeriksa kevalidan tanda tangan menggunakan rahasia (atau kunci publik untuk algoritma asimetris). Ini juga memastikan bahwa token tidak kedaluwarsa dan bahwa klaim sesuai dengan apa yang diharapkan oleh aplikasi Anda. Mengabaikan verifikasi dan percaya pada token yang sudah didekodifikasi adalah cara yang terjadi dalam penyalahgunaan otentikasi.

Berikut adalah contoh kode Node.js yang memverifikasi JWT dan menangani kasus-kasus umum:

import jwt from 'jsonwebtoken';

const SECRET = process.env.JWT_SECRET;

function verifyToken(token) {
  try {
    const payload = jwt.verify(token, SECRET, {
      algorithms: ['HS256'],  // whitelist — never allow 'none'
      audience: 'myapp',      // validate aud claim
    });

    // jwt.verify throws if exp is in the past, but be explicit:
    if (payload.exp < Math.floor(Date.now() / 1000)) {
      throw new Error('Token expired');
    }

    return payload;
  } catch (err) {
    // Never silently swallow verification failures
    throw new Error(`Invalid token: ${err.message}`);
  }
}

Klaim yang Perlu Diperiksa

Spesifikasi JWT menentukan klaim standar yang harus aktif diperiksa oleh server, bukan hanya dibaca:

Klaim	Arti	Validasi diperlukan?
exp	Timestamp kedaluwarsa	Selalu — token yang kadaluwarsa merupakan permukaan serangan nyata
iat	Timestamp saat dikeluarkan	Opsional, berguna untuk pemeriksaan max-age
sub	Subjek (biasanya ID pengguna)	Ya — pastikan sesuai dengan pengguna yang diharapkan
aud	Audien yang dimaksudkan	Ya — mencegah token dari layanan A digunakan di layanan B

Kebanyakan perangkat lunak JWT exp mengonfigurasi secara otomatis — tetapi hanya jika Anda mengatur konfigurasinya. Baca dokumentasi perangkat lunak Anda. Jangan asumsikan bahwa ini diaktifkan secara default.

Tiga Kesalahan yang Menyebabkan Pengembang Terkena Dampak

1. The alg: none Menyerang

Spesifikasi JWT memungkinkan nilai algoritma none, yang berarti tidak ada tanda tangan. Beberapa perangkat lunak — terutama yang lebih tua — menerima ini dan mengabaikan verifikasi tanda tangan secara keseluruhan. Seorang penyerang menghilangkan tanda tangan, mengatur "alg": "none" di header, dan membuat klaim yang sembarang. Server percaya terhadapnya.

Solusi: secara eksplisit putuskan algoritma yang diperbolehkan saat melakukan verifikasi. Jangan terima none. Contoh kode di atas menunjukkan hal ini dengan algorithms: ['HS256'].

2. Tidak Memverifikasi Kedaluwarsa

Mendekode token dan percaya pada payload tanpa memeriksa exp berarti token yang dikeluarkan bertahun-tahun lalu masih diterima. Jika sesi pengguna dihapus atau penyerang mencuri token lama, aplikasi Anda tidak akan tahu.

Solusi: anggap kedaluwarsa sebagai wajib, bukan opsional. Untuk memeriksa kapan token tertentu habis, gunakan IO Tools JWT Expiry Checker untuk mendekode exp klaim dan memberi tahu Anda secara tepat berapa banyak waktu yang tersisa — berguna untuk penanganan alur pembaruan tanpa harus menulis kode.

3. Menyimpan Token JWT di localStorage

localStorage dapat dibaca oleh JavaScript apa pun di halaman tersebut. Satu kelemahan XSS berarti penyerang dapat mengambil token otentikasi pengguna secara diam-diam. Berikut perbandingan antara opsi penyimpanan:

Penyimpanan	Risiko XSS	Risiko CSRF	Dapat diakses dari JavaScript	Catatan
localStorage	Tinggi	Tidak ada	Ya	Hindari untuk menyimpan token otentikasi
sessionStorage	Tinggi	Tidak ada	Ya	Risiko yang sama seperti localStorage
httpOnly cookie	Tidak ada	Sedang	TIDAK	Paling baik untuk otentikasi; pasangkan dengan SameSite + token CSRF
Penyimpanan di memori (variabel JS)	Rendah	Tidak ada	Ya (dalam konteks yang sama)	Kehilangan saat refresh; cocok untuk token dengan masa pakai pendek

Cookie httpOnly tidak dapat dibaca oleh JavaScript sama sekali, yang menghilangkan vektor penyerangan XSS secara total. Kompromi adalah eksposur terhadap CSRF, yang Anda tangani dengan SameSite=Strict atau token CSRF.

Token JWT vs Session: Pertukaran yang Jujur

Token JWT bersifat tanpa status — server memverifikasi tanpa mengakses database. Ini berguna dalam sistem terdistribusi di mana Anda tidak ingin setiap layanan mengakses penyimpanan sesi bersama.

Namun, tanpa status memiliki biaya nyata: Anda tidak dapat membatalkan token JWT sebelum kedaluwarsa. Jika pengguna keluar atau terkena serangan, token tetap valid hingga exp. Solusi (daftar token, masa pakai pendek + token pembaruan) ada, tetapi menambahkan kompleksitas dan sering kali menciptakan kembali apa yang sudah dilakukan oleh penyimpanan sesi.

Gunakan token JWT ketika: Anda memiliki beberapa layanan yang mengotentikasi permintaan secara independen, Anda ingin menyisipkan peran/izin secara langsung ke dalam token, atau token Anda memiliki masa pakai pendek dan latensi pembatalan dapat diterima.

Gunakan sesi ketika: Anda membutuhkan pembatalan segera (logout harus bekerja), Anda membuat aplikasi yang di-render di server, atau kelembutan lebih besar daripada skalabilitas tanpa status.

Inspeksi Token dalam Beberapa Detik

Perlu melihat apa yang ada di dalam token JWT saat ini? Terminal:

echo "YOUR.JWT.HERE" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

Atau lewatkan terminal — tempel token tersebut ke IO Tools Decoder JWT untuk mendapatkan pembagian terformat dari header dan payload. Kedua pendekatan tidak memverifikasi tanda tangan; mereka hanya mendekode. Untuk membaca masa kedaluwarsa secara cepat tanpa menulis kode, alat JWT Expiry Checker memberikan waktu dan waktu yang tersisa secara tepat.

Anda mungkin juga menyukai