Dalam pengembangan aplikasi full-stack dan keamanan sistem, saya perlu memahami apa yang terjadi setelah pengguna berhasil login: bagaimana request berikutnya dikenali, di mana status login disimpan, dan bagaimana akses dihentikan. Memilih teknologi autentikasi perlu dimulai dari alur tersebut.
Catatan ByteByteGo tentang cookies, sessions, JWT, dan PASETO menjadi titik awal tulisan ini. Saya menelaah hubungan keempatnya agar keputusan desain tidak berhenti pada perbandingan “mana yang lebih aman” atau “mana yang lebih mudah diskalakan”.
Ada beberapa penyederhanaan yang perlu diluruskan:
- Autentikasi dan otorisasi berbeda. Memastikan identitas pengguna belum menentukan data atau tindakan yang boleh diaksesnya.
- Keempat istilah ini berbeda lapisan. Cookie membawa data melalui browser; session menghubungkan request dengan status pengguna; JWT dan PASETO mengemas klaim dalam token.
- JWT tidak perlu memuat seluruh data pengguna. Token cukup membawa klaim yang diperlukan.
- PASETO membatasi pilihan kriptografi, tetapi keamanan aplikasi tetap bergantung pada validasi dan pengelolaan token.
Peta singkat
Istilah | Peran | Contoh |
Cookie | Menyimpan nilai di browser dan mengirimkannya sesuai aturan cookie | Cookie berisi ID session |
Session | Mempertahankan konteks pengguna antar-request | Record session yang merujuk pengguna |
JWT | Format klaim dengan perlindungan JWS atau JWE | Access token untuk API |
PASETO | Format token dengan kriptografi yang ditetapkan per versi dan tujuan | Token v4.local atau v4.public |
Jadi, cookie dan JWT dapat dipakai bersama. Session juga dapat menggunakan cookie sebagai pembawa ID-nya. Dasar pembagian ini dapat ditelusuri melalui MDN, OWASP Session Management, dan RFC 7519.
1. Cookie: cara browser membawa data
Server dapat mengirim cookie melalui header
Set-Cookie. Browser menyimpannya, lalu menyertakannya dalam header Cookie pada request yang memenuhi aturan domain, path, dan atribut lainnya. Nilainya dapat berupa preferensi maupun token login.Contoh header untuk ID session:
Set-Cookie: __Host-session=RANDOM_SESSION_ID; Path=/; Secure; HttpOnly; SameSite=LaxRANDOM_SESSION_ID hanya placeholder. Dalam aplikasi, nilainya harus dibuat dengan pembangkit acak kriptografis.- Secure membatasi pengiriman melalui HTTPS.
- HttpOnly mencegah JavaScript membaca cookie melalui API seperti
document.cookie.
- SameSite=Lax membatasi pengiriman lintas situs, dengan pengecualian tertentu seperti navigasi tingkat atas melalui method aman.
- Prefix __Host- mensyaratkan
Secure,Path=/, dan tanpa atributDomainpada browser yang mendukungnya.
Atribut cookie mengatur perilaku browser. Server tetap harus memvalidasi nilainya. Penjelasan atribut dan prefix tersedia di referensi Set-Cookie MDN.
2. Session: menghubungkan request dengan status login
Dalam pola session di server, browser memegang ID acak, sementara server menyimpan record yang merujuk pengguna dan masa berlaku. Session juga dapat dipakai sebelum login, misalnya untuk mempertahankan konteks pengunjung.
Alur login sederhananya:
- Server memverifikasi kredensial.
- Server membuat session dan mengirim ID-nya melalui cookie.
- Request berikutnya membawa cookie; server mencari dan memvalidasi session.
- Saat logout, server membatalkan session dan menghapus cookie browser.
ID perlu diperbarui setelah autentikasi atau perubahan tingkat hak akses untuk mengurangi risiko session fixation. Batas waktu tidak aktif dan batas waktu absolut ditegakkan di server.
Untuk beberapa instance aplikasi, record session perlu tersedia secara konsisten, misalnya melalui database bersama. Konsekuensinya adalah pengelolaan penyimpanan dan ketersediaannya, bukan berarti session tidak dapat diskalakan.
Rincian keamanan pola ini ada di OWASP Session Management.
3. JWT: klaim yang dapat diverifikasi
JSON Web Token adalah format pembawa klaim. Klaim dapat dilindungi dengan signature atau MAC melalui JWS, dan dapat dienkripsi melalui JWE. JWT bertanda tangan yang umum ditemui memiliki tiga bagian: header, payload, dan signature.
Contoh payload ilustratif:
{
"sub": "user-42",
"iss": "https://auth.example.com",
"aud": "orders-api",
"exp": 1893456000
}sub mengidentifikasi subjek, iss penerbit, aud penerima yang dituju, dan exp batas waktu berupa NumericDate. Contoh ini bukan token siap pakai. Bentuk klaim tersebut dijelaskan dalam RFC 7519.Payload JWS dapat dibaca; Base64url bukan enkripsi. Hindari password dan data rahasia di dalamnya. Mendecode payload juga belum membuktikan keabsahan token.
Penerima harus memverifikasi perlindungan kriptografinya, membatasi algoritma yang diterima, memakai kunci tepercaya, dan memvalidasi klaim sesuai kontrak: termasuk penerbit, audience, kedaluwarsa, serta jenis token. Token yang sah untuk satu API belum tentu sah untuk API lain. Panduannya ada di RFC 8725.
Keuntungan token mandiri adalah penerima dapat memverifikasi klaim tanpa mengambil record session setiap kali. Namun, menghapus token di browser tidak membatalkan salinan yang telah dicuri. Jika validasi hanya mengandalkan token, token tersebut dapat tetap diterima sampai kedaluwarsa.
Pencabutan sebelum kedaluwarsa membutuhkan mekanisme tambahan, misalnya daftar token yang dicabut. Pemeriksaan itu membawa state kembali ke sistem. Karena itu, JWT tidak otomatis membuat seluruh aplikasi stateless atau lebih mudah diskalakan. Pertimbangan ini dibahas di OWASP JSON Web Token.
4. PASETO: pilihan kriptografi yang lebih dibatasi
Platform-Agnostic SEcurity TOkens menetapkan konstruksi kriptografi menurut versi dan tujuan token. Sebagai contoh, spesifikasi versi 4 membedakan:
- v4.local: payload dienkripsi dan diautentikasi dengan kunci simetris.
- v4.public: payload ditandatangani dengan private key dan diverifikasi dengan public key; isinya tidak dienkripsi.
Misalnya, penerbit membuat
v4.public agar service penerima dapat memverifikasi token dengan public key tanpa memiliki private key penerbit. Bentuk dan operasinya dijelaskan dalam spesifikasi PASETO v4.Pembatasan tersebut mengurangi ruang kesalahan pemilihan algoritma. Library tetap perlu mengikat kunci pada versi dan tujuan yang benar, sebagaimana dijelaskan dalam Algorithm Lucidity.
Aplikasi juga tetap harus memeriksa klaim yang diperlukan. PASETO mendefinisikan klaim seperti
iss, aud, dan exp; berbeda dari NumericDate JWT, klaim waktu PASETO memakai string RFC 3339. Lihat Registered Claims. Format token tidak menggantikan rancangan logout dan pencabutan akses.5. Penyimpanan dan pengiriman menentukan risiko browser
Mengganti format token tidak menghilangkan risiko browser:
- Cookie dikirim otomatis. Request yang mengubah data perlu perlindungan CSRF, misalnya mekanisme bawaan framework dengan token CSRF dan pemeriksaan origin.
SameSitemenjadi lapisan perlindungan tambahan yang dipilih sesuai alur aplikasi.
- localStorage dapat dibaca JavaScript. Celah XSS dapat mencuri token di dalamnya.
HttpOnlymenghalangi pembacaan cookie, tetapi skrip berbahaya masih dapat menjalankan request dari halaman pengguna.
- JWT dalam cookie tetap mengikuti aturan cookie. Isi cookie berupa JWT tidak membuatnya kebal CSRF.
Dasarnya ada di OWASP CSRF Prevention dan OWASP HTML5 Security.
Terakhir, identitas yang sudah diverifikasi tetap harus melewati pemeriksaan izin pada setiap request. Sebagai contoh, pengguna yang login tidak otomatis boleh membaca pesanan milik pengguna lain. Ini merupakan tanggung jawab otorisasi, sesuai OWASP Authorization.
Penutup
Urutan yang saya sarankan adalah memahami cookie dan alur session terlebih dahulu, lalu mempelajari klaim, verifikasi, dan pencabutan token. Setelah itu, bandingkan JWT dan PASETO berdasarkan kebutuhan sistem serta dukungan library yang akan dipakai.
Untuk aplikasi web yang saya kendalikan frontend dan backend-nya, session di server dengan cookie yang dilindungi layak menjadi titik awal evaluasi. Jika beberapa service perlu memverifikasi klaim secara mandiri, format token perlu dipertimbangkan bersama batas kepercayaan dan kebutuhan pencabutannya.
Pertanyaan desain yang saya bawa kembali ke gambaran sistem utuh adalah: ketika pengguna logout atau kehilangan hak akses, kapan setiap bagian sistem benar-benar berhenti menerima request-nya? Jawaban itu lebih membantu daripada memilih teknologi hanya dari labelnya.