JWT vs Session
Membandingkan mental model session identifier dan JWT tanpa masuk ke token signing, OAuth, atau membangun auth server sendiri.
Tujuan belajar
- Menjelaskan session identifier sebagai rujukan state yang server kenali
- Menjelaskan JWT sebagai token dengan claims yang diverifikasi sesuai provider contract
- Membedakan lokasi penyimpanan dari mekanisme authorization
- Menghindari asumsi bahwa decode client adalah verifikasi security
Isi lesson
4 blok- 1.JWT dan session adalah contract, bukan label keamananBelum selesaiWajib
- 2.Bandingkan pertanyaan debug, bukan algoritma tokenBelum selesaiWajib
- 3.Writing practiceBelum selesaiWajib
- 4.RingkasanBelum selesaiWajib
JWT dan session adalah contract, bukan label keamanan
WajibSession-based auth sering memakai identifier opaque yang browser kirim ke server. Server mencari atau memverifikasi session lalu memutuskan identity dan permission. JWT adalah token yang dapat membawa claims dan biasanya diverifikasi oleh server atau provider sesuai key serta policy mereka. Keduanya dapat dikirim melalui cookie atau mekanisme lain; cara token sampai ke browser tidak otomatis membuat authorization aman atau tidak aman.
Untuk frontend, pertanyaan praktisnya adalah: siapa menetapkan credential, request mana yang membawanya, apakah browser perlu credentials option, kapan session kedaluwarsa, bagaimana refresh terjadi, dan endpoint mana yang memverifikasi authorization. Membaca payload JWT di browser bukan verifikasi signature dan tidak boleh menjadi satu-satunya dasar role atau akses data. Ikuti contract provider serta server boundary yang sudah dipilih project.
Bagian ini memengaruhi progres lesson.
Bandingkan pertanyaan debug, bukan algoritma token
Wajibconst sessionQuestions = [
"Apakah response login menetapkan cookie session?",
"Apakah request dashboard membawa cookie sesuai scope?",
"Apakah server masih menganggap session valid?",
];
const jwtQuestions = [
"Siapa menerbitkan token dan siapa memverifikasinya?",
"Kapan token atau refresh flow kedaluwarsa?",
"Apakah server memverifikasi claims sebelum memberi data?",
];Dua daftar ini membantu frontend mengajukan pertanyaan yang dapat dijawab oleh Network panel, provider docs, atau backend team. Jangan mencoba membuat token, mengubah claims, atau memverifikasi cryptography di exercise ini. Project dapat memakai provider yang mengelola session serta token di balik API; yang penting adalah mengetahui boundary dan symptom yang dapat dilihat frontend.
Bagian ini memengaruhi progres lesson.
Writing practice
WajibLatihan menulis
Tulis note singkat untuk team tentang satu auth flow: apakah project memakai session cookie, JWT, atau provider-managed flow yang belum kamu pastikan. Jelaskan apa yang diketahui dari request/response, apa yang belum diketahui, request atau browser state yang akan diperiksa, dan mengapa browser decode bukan authorization check. Jangan menyalin token atau mengklaim format token menentukan semua security property.
Tulis draft dulu sebelum menandai writing practice selesai.
0/350 karakter
Checklist panduan
Checklist ini hanya panduan. Kamu tidak harus mencentang semuanya.
Ringkasan
Wajib- Session identifier dan JWT adalah dua mental model auth contract yang berbeda.
- Keduanya dapat berinteraksi dengan cookie atau provider-managed browser flow.
- Decode client bukan verification atau authorization check.
- Debug dari request, expiry, response logout, serta server behavior yang dapat dibuktikan.
- Berikutnya, kita melihat same-origin policy dan CORS saat browser perlu membaca API dari origin lain.
Bagian ini memengaruhi progres lesson.
Langkah berikutnya
Selesaikan bagian penting lesson ini
Lanjutkan blok wajib berikutnya: JWT dan session adalah contract, bukan label keamanan.