JSON Web Token atau JWT adalah teknologi yang luar biasa untuk mengelola otentikasi dalam aplikasi modern. Sifatnya yang ringkas dan stateless membuatnya menjadi pilihan favorit untuk mengamankan API, terutama dalam arsitektur microservices, Single Page Applications (SPA), dan aplikasi mobile. Kemudahan verifikasinya di sisi server tanpa perlu memeriksa database sesi memberikan peningkatan performa dan skalabilitas yang signifikan. Hal ini sangat praktis.

Namun, kemudahan ini seringkali disalahpahami. Banyak pengembang, terutama yang baru mengenal JWT, jatuh ke dalam perangkap berbahaya. Mereka memperlakukan JWT seolah-olah sebuah brankas digital terenkripsi yang bisa digunakan untuk menyimpan dan mengirimkan berbagai macam data dengan aman. Ini adalah asumsi yang salah kaprah dan bisa membuat aplikasi Anda jebol seketika. JWT pada dasarnya dirancang sebagai sebuah paspor atau tiket, bukan sebagai dompet berisi semua data berharga Anda. Menyimpan data yang salah di dalamnya sama seperti menulis PIN ATM Anda di belakang kartu debit itu sendiri. Artikel ini akan membahas secara tuntas data sensitif apa saja yang haram hukumnya untuk disimpan di dalam JWT.

Baca juga: Masa Depan RPL: Bagaimana AI Akan Mengubah Cara Kita Ngoding

Mengapa JWT Bukan Brankas Rahasia? Membedah Anatomi Token

Sebelum kita masuk ke daftar hitam, kita harus memahami mengapa JWT tidak aman untuk menyimpan data sensitif. Sebuah JWT terdiri dari tiga bagian yang dipisahkan oleh titik: Header, Payload, dan Signature.

• Header: Berisi metadata tentang token, seperti tipe token (typ) dan algoritma penandatanganan (alg).
• Payload: Berisi klaim atau data tentang pengguna, seperti ID pengguna dan hak aksesnya.
• Signature: Tanda tangan digital yang digunakan server untuk memverifikasi bahwa token tersebut asli dan tidak dimanipulasi.

Kesalahpahaman fatal terletak pada bagian Payload. Bagian ini tidak dienkripsi, melainkan hanya di-encode menggunakan Base64Url. Encoding adalah proses mengubah data menjadi format lain agar bisa ditransmisikan dengan aman, tetapi tidak menyembunyikan isinya. Siapa pun yang mendapatkan token Anda bisa dengan mudah menyalin bagian Payload, memasukkannya ke dalam dekoder Base64 online, dan melihat semua isinya dalam bentuk teks biasa. Analogi yang paling tepat adalah kartu pos. Anda bisa memastikan kartu pos itu dikirim oleh orang yang benar (melalui tanda tangan/signature), tetapi semua orang yang memegang kartu pos itu di sepanjang jalan bisa membaca tulisannya (Payload).

Daftar Hitam: Data Paling Berbahaya untuk Disimpan di Payload

Dengan pemahaman bahwa Payload JWT dapat dibaca oleh siapa saja, berikut adalah daftar data yang sama sekali tidak boleh Anda simpan di dalamnya. Menyimpan salah satu dari ini akan menciptakan kerentanan keamanan yang serius.

• Kata Sandi Pengguna (Passwords): Ini adalah dosa terbesar dalam penggunaan JWT. Tidak ada alasan apa pun untuk menyimpan kata sandi pengguna, baik dalam bentuk teks biasa, dienkripsi, maupun di-hash, di dalam Payload. Jika token bocor, informasi ini bisa disalahgunakan untuk serangan lebih lanjut atau, jika hash-nya lemah, bisa dipecahkan.
• Informasi Identitas Pribadi (Personally Identifiable Information – PII): Hindari menyimpan data PII yang lengkap dan sensitif. Ini termasuk namun tidak terbatas pada nomor KTP, nomor telepon, alamat rumah lengkap, tanggal lahir, atau informasi pribadi lainnya yang dapat digunakan untuk pencurian identitas. Kebocoran data ini tidak hanya menghancurkan kepercayaan pengguna tetapi juga bisa melanggar peraturan perlindungan data seperti UU PDP di Indonesia.
• Data Keuangan dan Pembayaran: Jangan pernah menyimpan nomor kartu kredit, nomor rekening bank, kode CVV, atau detail keuangan lainnya di dalam JWT. Risiko kerugian finansial langsung bagi pengguna sangat tinggi jika token ini jatuh ke tangan yang salah.
• Kunci Rahasia atau API Key Internal: Menyimpan satu rahasia di dalam rahasia lainnya adalah praktik yang sangat buruk. Jika Anda menyimpan API key untuk layanan internal atau pihak ketiga di dalam JWT, kebocoran token tersebut akan menyebabkan efek domino. Peretas tidak hanya mendapatkan akses ke akun pengguna, tetapi juga ke sistem internal lain yang Anda miliki.
• Izin (Permissions) yang Terlalu Detail: Meskipun menyimpan peran pengguna ("admin", "user") adalah hal yang umum, hindari menyimpan struktur izin yang sangat rinci dan kompleks dalam bentuk objek besar di dalam Payload. Hal ini tidak hanya membuat ukuran token membengkak (yang bisa menjadi masalah performa), tetapi juga membocorkan terlalu banyak informasi tentang arsitektur keamanan internal aplikasi Anda kepada calon penyerang.

Jadi, Apa yang Boleh Disimpan? Data Aman untuk Payload JWT

Setelah mengetahui apa yang tidak boleh disimpan, lantas data apa yang aman dan memang seharusnya berada di dalam Payload JWT. Data yang ideal adalah informasi minimal yang dibutuhkan oleh server untuk mengidentifikasi pengguna dan mengotorisasi permintaannya tanpa perlu sering-sering memeriksa database.

• User Identifier (Klaim sub): Ini adalah klaim paling penting. Simpan ID unik pengguna di sini. Sebaiknya gunakan ID yang tidak berurutan dan tidak mudah ditebak, seperti UUID, daripada menggunakan ID inkremental dari database.
• Peran Pengguna (Roles): Menyimpan peran tingkat tinggi dalam bentuk array sederhana sangat dianjurkan. Contohnya: "roles": ["user", "premium_member"].
• Klaim Standar Wajib: Manfaatkan klaim standar yang sudah ditentukan untuk mengelola siklus hidup token. Klaim exp (waktu kedaluwarsa) wajib ada untuk membatasi masa berlaku token. Klaim lain yang berguna adalah iss (penerbit token) dan aud (audiens yang dituju) untuk memastikan token digunakan oleh dan untuk aplikasi yang benar.
• Metadata Tidak Sensitif: Data lain yang tidak sensitif dan berguna untuk pengalaman pengguna bisa disertakan, misalnya preferensi bahasa atau tema UI.

Paradigma yang Benar: JWT sebagai Tiket, Bukan Dompet

Untuk menyimpulkan semuanya, cara terbaik untuk memikirkan JWT adalah sebagai sebuah tiket konser atau tiket masuk bioskop. Tiket tersebut berisi informasi penting untuk verifikasi: siapa Anda (ID tiket), kategori tempat duduk Anda (peran), dan kapan pertunjukannya (waktu kedaluwarsa). Petugas di pintu (server) hanya perlu melihat tiket itu untuk memberi Anda akses. Mereka tidak perlu tahu alamat rumah Anda, isi rekening bank Anda, atau riwayat hidup Anda.

Baca juga: Mahasiswa Teknokrat Berprestasi sebagai Juara KTI dan Best Expo di PIMPI 2025 IPB University, Memberikan Dampak Positif

Jika server memerlukan informasi yang lebih detail tentang Anda, server harus menggunakan ID yang ada di tiket (klaim sub dari JWT) untuk mencarinya di sistem internal yang aman, yaitu database. JWT hanyalah alat untuk otorisasi, bukan alat untuk transportasi data. Dengan mengadopsi paradigma ini, Anda dapat memanfaatkan kekuatan JWT secara maksimal sambil menjaga data pengguna dan keamanan aplikasi Anda tetap pada level tertinggi. Jangan biarkan kesalahan sepele dalam implementasi JWT menjadi penyebab aplikasi Anda jebol.

Penullis: Indra Irawan