Cookie vs Token: Kapan Pakai yang Mana

Stempel tangan vs kartu anggota

Konser memakai cap tangan (otomatis diperiksa penjaga, tapi luntur kalau keringatan). Gym memakai kartu anggota (kamu yang menunjukkan, berlaku di semua cabang). Cookie session seperti cap tangan: browser mengirim otomatis, tapi butuh perlindungan CSRF. Token JWT seperti kartu anggota: kamu yang membawa dan menunjukkan manual, bebas CSRF tapi harus dijaga dari pencurian.

Kenapa perdebatan ini tidak ada jawaban mutlak

Keduanya menyelesaikan masalah yang sama (HTTP stateless) dengan trade-off berbeda. Pilihan yang tepat tergantung jenis aplikasimu: web klasik, SPA + API terpisah, atau mobile. Memahami trade-off-nya lebih penting daripada menghafal "yang benar".

Contoh 1: kapan cookie menang

Aplikasi web klasik (server me-render HTML, misal Laravel Blade):

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

Browser mengirim otomatis, HttpOnly melindungi dari XSS, SameSite melindungi dari CSRF. Tidak ada kode auth di frontend sama sekali. Untuk web tradisional, ini setup paling sederhana dan aman.

Contoh 2: kapan token menang

SPA (app.contoh.id) + API (api.contoh.id) + aplikasi mobile:

// Satu token untuk semua klien
const res = await fetch("https://api.contoh.id/profil", {
  headers: { "Authorization": "Bearer " + token }
});

Mobile tidak punya cookie otomatis yang praktis; token bekerja seragam di web, iOS, dan Android. Server stateless (tidak menyimpan session) sehingga mudah diskalakan horizontal.

Kesalahan umum

Salah: memakai JWT tapi menyimpannya seperti session. Token disimpan di database server dan dicek tiap request: kehilangan semua keunggulan stateless. Yang benar: kalau butuh cek database tiap request, pakai session biasa saja.

Salah: memakai cookie untuk API yang dipakai mobile. Cookie lintas domain di mobile rumit. Yang benar: API multi-klien pakai token.

Salah: menyimpan JWT di localStorage untuk aplikasi sensitif. Rentan XSS. Yang benar: pertimbangkan httpOnly cookie untuk menyimpan JWT (menggabungkan keduanya), atau perkuat pertahanan XSS.

Salah: fanatik satu kubu. "Cookie sudah kuno" atau "JWT overhyped". Yang benar: pilih berdasarkan arsitektur, bukan tren.

Keputusan dalam 30 detik

Tanya tiga hal ini berurutan:

1. Ada aplikasi mobile? Ya -> token. Tidak -> lanjut.
2. Frontend dan API beda domain? Ya -> token (atau cookie + SameSite=None). Tidak -> lanjut.
3. Aplikasi web klasik server-rendered? Ya -> cookie session.

Tiga pertanyaan, satu jawaban. Kebanyakan kebingungan cookie-vs-token hilang begitu arsitekturnya jelas. Dan ingat pola hybrid: access token pendek di memori + refresh token di httpOnly cookie untuk SPA yang serius soal keamanan.

Catatan teknis: Pola hybrid populer: JWT access token berumur pendek di memori + refresh token di httpOnly cookie. Mendapat keamanan cookie dan fleksibilitas token sekaligus. Ini standar untuk SPA modern yang serius soal keamanan.