Access Token vs Refresh Token: Menjaga Keamanan Login JWT

Kelemahan Terbesar JWT (JSON Web Token)

Di artikel sebelumnya kita bahas betapa hebat dan ringannya JWT untuk sistem *Login*. Tapi, JWT punya satu kelemahan fatal: Server tidak bisa menghancurkan/membatalkan JWT secara instan!

Jika kamu mengatur Token JWT-mu aktif selama 1 Tahun, lalu token itu tidak sengaja tercopy oleh *hacker* yang meminjam laptopmu, maka *hacker* tersebut memiliki Akses Penuh selama 1 Tahun penuh ke dalam akunmu. Servermu tidak akan menolaknya karena tanda tangannya valid.

Untuk mengatasi bahaya laten ini, arsitektur keamanan membaginya menjadi 2 Token berbeda: Access Token dan Refresh Token.

1. Access Token (Si Tiket Konser Cepat Basi)

Saat *user* pertama kali Login (masukkan email & password), Server akan memberikan sebuah Access Token.

• Fungsi: Digunakan di Header setiap kali Frontend memanggil API (misal: mengambil data rahasia profil).
• Aturan Emas: Waktu kedaluwarsanya (Expired Time) dibuat SANGAT SINGKAT (misalnya hanya 15 menit atau maksimal 1 jam).
• Manfaat Keamanan: Jika *hacker* berhasil mencuri *Access Token* ini dari WiFi publik, *hacker* itu hanya punya waktu 15 menit untuk menggunakannya. Setelah 15 menit, token itu menjadi sampah.

2. Refresh Token (Si Kunci Brankas)

Tapi, kalau token mati dalam 15 menit, apakah *user* harus mengetik *password* ulang setiap 15 menit? Tentu mereka akan marah. Di sinilah Refresh Token bekerja.

Bersamaan dengan *Access Token* tadi, server juga memberikan Refresh Token secara diam-diam. Waktu kedaluwarsanya dibuat Lama (Misal: 7 hari atau 30 hari).

• Cara Kerja Rahasianya: Ketika *Access Token* mati di menit ke-16, *Frontend* (secara otomatis dan tidak terlihat oleh mata *user*) akan langsung mengirimkan Refresh Token ke sebuah *Endpoint* API khusus di *Backend*. (Misal: POST /api/refresh-token).
• Validasi Server: Server akan mengecek ke dalam databasenya. "Apakah Refresh Token ini masih valid? Ya. Apakah akun ini belum di-ban? Ya." Jika aman, server akan mencetak Access Token Baru (yang umurnya 15 menit lagi) dan mengirimkannya ke *Frontend*.
• Kenyamanan User: User tetap bisa asyik memakai aplikasi berjam-jam tanpa pernah sadar bahwa token mereka sebenarnya sedang diganti setiap 15 menit di belakang layar!

Cara Aman Menyimpannya

Sebagai *Best Practice* Frontend: Simpanlah Access Token di memori sementara (State/Redux) agar sangat sulit disadap. Dan simpanlah Refresh Token di dalam HttpOnly Cookie (Cookie yang tidak bisa disentuh atau dibaca oleh JavaScript / XSS Attack sama sekali).