JWT vs Session: Mana Lebih Cocok untuk Autentikasi Login?

Saat membuat fitur login, hampir semua developer pemula bertemu pertanyaan yang sama: pakai JWT atau session? Perdebatan jwt vs session sering terdengar seperti pertarungan antara cara lama dan cara modern. Padahal keduanya hanyalah alat, dan masing-masing punya situasi yang cocok.

Artikel ini menjelaskan cara kerja keduanya dengan bahasa sederhana, membandingkan kelebihan dan kekurangannya, lalu membantu kamu memilih sesuai kebutuhan proyek.

Masalah yang Diselesaikan Keduanya

HTTP itu stateless. Setiap request berdiri sendiri, dan server tidak otomatis ingat bahwa kamu baru saja login satu detik lalu. Karena itu, setelah login berhasil, server perlu cara untuk mengenali kamu di request berikutnya tanpa meminta password lagi.

Di sinilah jwt vs session muncul sebagai dua pendekatan yang berbeda untuk masalah yang sama.

Cara Kerja Session

Bayangkan kamu menitipkan jaket di tempat penitipan dan menerima nomor tiket. Jaketnya tersimpan di tempat penitipan, kamu hanya memegang nomornya.

Session bekerja persis begitu:

Kamu login dengan email dan password.
Server membuat data session (siapa kamu, kapan berakhir) dan menyimpannya di memori, database, atau Redis.
Server mengirim session ID ke browser lewat cookie.
Di setiap request, browser mengirim cookie itu otomatis. Server mencari ID tersebut di penyimpanannya dan mengenali kamu.

Intinya, data pengguna disimpan di server, sedangkan browser hanya memegang ID acak.

Cara Kerja JWT

JWT (JSON Web Token) lebih mirip tiket konser yang dicap. Semua informasi penting tertulis di tiketnya, dan petugas cukup memeriksa cap untuk tahu tiket itu asli.

Alurnya:

Kamu login dengan email dan password.
Server membuat token berisi data singkat (misalnya ID pengguna dan peran) lalu menandatanganinya dengan kunci rahasia.
Token dikirim ke klien, yang menyimpannya.
Di setiap request, klien mengirim token itu. Server cukup memverifikasi tanda tangannya tanpa mencari apa pun di penyimpanan.

Satu JWT terdiri dari tiga bagian yang dipisah titik: header, payload, dan signature. Spesifikasi lengkapnya ada di dokumentasi JWT. Ingat bahwa payload hanya di-encode, bukan dienkripsi, jadi jangan simpan data sensitif seperti password di dalamnya.

Perbandingan JWT vs Session

Aspek	Session	JWT
Lokasi data	Di server	Di dalam token (klien)
Skalabilitas	Perlu penyimpanan bersama	Mudah, server tanpa status
Mencabut akses	Mudah, hapus session	Sulit sebelum token kedaluwarsa
Ukuran request	Kecil (hanya ID)	Lebih besar
Cocok untuk	Web dengan server tunggal atau SSR	API, mobile app, banyak layanan

Kelebihan dan Kekurangan Session

Kelebihan:

Mudah dicabut. Kalau akun diretas, hapus session dan pengguna langsung keluar.
Data sensitif tetap di server.
Pola yang matang dan didukung hampir semua framework.

Kekurangan:

Butuh penyimpanan. Saat server lebih dari satu, kamu perlu penyimpanan terpusat seperti Redis.
Rentan terhadap serangan CSRF jika cookie tidak diamankan dengan benar.

Kelebihan dan Kekurangan JWT

Kelebihan:

Server tidak perlu menyimpan status login, jadi mudah di-scale.
Cocok untuk beberapa layanan yang berbagi satu sistem login.
Praktis untuk aplikasi mobile dan API publik.

Kekurangan:

Token yang sudah dikeluarkan sulit dibatalkan sebelum masa berlakunya habis.
Ukurannya lebih besar dari session ID.
Salah menyimpan token di klien bisa membuka celah keamanan.

Di Mana JWT Sebaiknya Disimpan?

Ini kesalahan yang paling sering dilakukan pemula. Menyimpan JWT di localStorage memang mudah, tetapi token bisa dibaca oleh JavaScript apa pun di halaman, termasuk skrip jahat dari serangan XSS.

Pilihan yang lebih aman adalah cookie dengan atribut HttpOnly, Secure, dan SameSite:

javascript

res.cookie("token", jwtToken, {
  httpOnly: true,   // tidak bisa dibaca JavaScript
  secure: true,     // hanya lewat HTTPS
  sameSite: "lax",  // membantu mencegah CSRF
  maxAge: 15 * 60 * 1000 // 15 menit
});

Kalau kamu memakai cookie lintas domain, kamu mungkin akan bertemu error yang dibahas di artikel CORS error dan cara memperbaikinya.

Jalan Tengah: Access Token dan Refresh Token

Untuk mengatasi sulitnya mencabut JWT, banyak aplikasi memakai dua token:

Access token berumur pendek (misalnya 15 menit) untuk mengakses API.
Refresh token berumur panjang, disimpan lebih aman dan bisa dicabut di server, untuk meminta access token baru.

Dengan pola ini, kamu mendapat kemudahan JWT sekaligus kemampuan mencabut akses seperti pada session.

Kapan Memilih Mana?

Pilih session jika:

Aplikasimu website biasa dengan server rendering.
Kamu butuh logout paksa atau pencabutan akses yang cepat.
Aplikasi dijalankan di satu atau beberapa server dengan penyimpanan bersama.

Pilih JWT jika:

Kamu membangun API untuk aplikasi mobile atau banyak klien. Bila kamu masih menimbang gaya API-nya, baca juga REST API vs GraphQL.
Beberapa layanan perlu memakai sistem login yang sama.
Kamu siap mengelola masa berlaku dan refresh token dengan benar.

Satu hal yang sering terlupa: jangan memilih JWT hanya karena terdengar lebih modern. Untuk banyak proyek kecil, session sudah lebih sederhana dan lebih aman.

Kesimpulan

Dalam perdebatan jwt vs session, tidak ada pemenang mutlak. Session unggul dalam kemudahan mencabut akses dan kesederhanaan, sedangkan JWT unggul dalam fleksibilitas untuk API dan sistem terdistribusi. Pilih berdasarkan arsitektur dan kebutuhan keamanan proyekmu, bukan berdasarkan tren.

Mulailah dari yang paling sederhana yang memenuhi kebutuhan, lalu tambahkan kompleksitas hanya saat memang diperlukan.