cookie vs. sesi vs jwt


12

Saya membaca tentang otentikasi / otorisasi dalam aplikasi web. Adakah yang bisa mengkonfirmasi / memperbaiki pengetahuan saya saat ini?

  • Cookie: dalam versi awalnya, file teks dengan klien unik Id semua informasi lain yang diperlukan tentang klien (misalnya peran)

  • Sesi: hanya id klien unik yang dikirim dalam file (juga disebut cookie), semua yang lain disimpan di server

  • JWT: semuanya disimpan dalam token (yang juga bisa disimpan dalam file teks, yang juga disebut cookie)

Terima kasih atas umpan baliknya!

Jawaban:


12

Cookie: dalam versi awalnya, file teks dengan klien unik Id semua informasi lain yang diperlukan tentang klien (misalnya peran)

Cookie adalah tuple yang key-valueawalnya ditujukan untuk menyimpan data yang terkait dengan aktivitas klien. Retensi ini adalah apa yang kita ketahui sebagai sesi atau status aplikasi . Pada dasarnya, mereka dibuat untuk menahan keadaan aplikasi web; lebih khusus, keadaan di sisi klien. (1)

Cookie biasanya disetel oleh server melalui header respons ( Set-Cookie key=value). Namun, mereka juga dapat diatur oleh klien. Misalnya, oleh DOM ( document.cookie).

Satu hal penting yang perlu diketahui tentang cookie adalah mereka tidak mengidentifikasi pengguna. Mereka lebih mengaitkan data terna - client - server / path . (3)

Kami biasanya mengaitkan cookie dengan file karena pada hari-hari awal browser web mereka harus tetap mempertahankan cookie, menjadi file dukungan yang paling layak. Browser hari ini menyimpan cookie (antara lain) di penyimpanan lokal (DB yang disematkan).

Sesi: hanya id klien unik yang dikirim dalam file (juga disebut cookie), semua yang lain disimpan di server.

Menurut sesi, saya kira maksud Anda sesi server . Seperti yang saya komentari, sesi juga dapat diimplementasikan di sisi klien. Perbedaannya dengan sesi sisi klien adalah bahwa data disimpan di suatu tempat di sisi server. (2) Dalam skenario seperti itu, yang kita dapatkan adalah id sesi; dan kami mendapatkannya dalam bentuk cookie. Tanpa id sesi, server tidak akan dapat menghubungkan permintaan yang masuk dengan aktivitas klien sebelumnya. (3) Misalnya, pengguna yang diautentikasi, keranjang belanja, dll.

Dalam kasus apa pun, ID sesi tidak harus mengidentifikasi pengguna. Ini mengaitkan keadaan aplikasi tertentu dengan klien web. Sesi mungkin atau mungkin tidak mengandung data pengguna.

Dalam aplikasi terdistribusi, sesi harus serial untuk alasan yang jelas. Jika disimpan dalam memori, penyimpanan (komponen) dalam memori harus serial. Solusi umum adalah menyimpan sesi dalam file. Atau dalam DB NoSQL seperti Redis.

Mengenai keamanan. Sesi sisi server lebih aman daripada sisi klien. Klien lebih rentan terhadap ancaman karena pengguna biasanya tidak menyadari begitu banyak ancaman yang mereka hadapi. Setidaknya bukan pengguna biasa.

Di sisi lain, menyerang infrastruktur sisi server bukanlah hal yang sepele.

JWT: semuanya disimpan dalam token (yang juga bisa disimpan dalam file teks, yang juga disebut cookie)

Tidak juga. JWT menyimpan data terutama terkait dengan otorisasi dan penerbit token.

Meskipun mereka digunakan untuk mengandung ID pengguna (sub), kami menemukan JWT yang tidak mengidentifikasi pengguna yang diautentikasi. Misalnya, token untuk sesi tamu. Konten utama JWT adalah klaim ; item yang akan diperiksa oleh proses otorisasi.

Penting untuk diingat bahwa JWT bukan penyimpanan global . The sesi atau negara aplikasi masih harus disimpan di suatu tempat dan dikelola secara mandiri.

Mengenai JWT, ini sering disimpan sebagai cookie, meskipun mereka juga dapat disimpan di penyimpanan lokal. Selain itu, komunitas OWASP menganggap sessionStorage menjadi lebih aman untuk browser web. Namun, itu tergantung pada versi browser .


1: World Wide Web dimaksudkan untuk menjadi tanpa kewarganegaraan. Jika kita ingin membangun aplikasi sisi server tanpa kewarganegaraan, sesi harus disimpan di suatu tempat di sisi klien.

2: Mengubah aplikasi sisi server menjadi aplikasi stateful .

3: Klien sebagai aplikasi, bukan sebagai pengguna.


Saya perhatikan bahwa beberapa, seperti konfigurasi Ruby on Rails default, menyimpan seluruh objek "sesi" dalam cookie (hari ini biasanya dienkripsi), yang mungkin hanya berisi sesuatu seperti user_iduntuk pengguna yang login.
Fire Lancer

7

Cookie: dalam versi awalnya, file teks dengan klien unik Id semua informasi lain yang diperlukan tentang klien (misalnya peran)

Definisi cookie Anda tidak benar-benar menggambarkan apa yang mereka lakukan. Cookie adalah pasangan nilai kunci yang ditetapkan melalui tajuk respons HTTP ( Set-Cookie) oleh server dan disimpan oleh klien yang mendukungnya. Cookie dikirim kembali dengan setiap permintaan berikutnya (di Cookieheader) untuk skema permintaan yang cocok, host, jalur, https sementara cookie belum kedaluwarsa. Anda dapat menyimpan apa pun yang Anda inginkan dalam cookie, dan memungkinkan Anda mendukung status pada protokol stateless HTTP.

Contoh pertukaran cookie terlihat seperti ini:

masukkan deskripsi gambar di sini

Sesi: hanya id klien unik yang dikirim dalam file (juga disebut cookie), semua yang lain disimpan di server

Itu cukup benar. Sesi adalah data yang disimpan di sisi server tentang sesi pengguna saat ini. Agar ini berfungsi dalam protokol stateless seperti HTTP, pengguna harus mengirim ID sesi mereka dengan setiap permintaan, sehingga server dapat mengambil sesi yang benar untuk pengguna. ID sesi biasanya disimpan dalam cookie (lihat di atas). Ini bukan cookie yang berbeda dari cookie lainnya, datanya hanya ID server untuk sesi pengguna.

JWT: semuanya disimpan dalam token (yang juga bisa disimpan dalam file teks, yang juga disebut cookie)

Itu cukup benar. Semuanya disimpan dalam token. Token dapat disimpan dalam cookie (lihat di atas). Ini merupakan alternatif untuk sesi server, dan ini berfungsi karena token ditandatangani dan diverifikasi oleh server, sehingga token tidak dapat diubah atau dipalsukan, dan aman untuk disimpan di sisi klien.


JWT biasanya tidak disimpan dalam cookie dalam pengalaman saya. Bisa saja, tetapi lebih sering saya melihat mereka di header mereka sendiri (atau sering header Otorisasi) dalam perjalanan ke server dan disimpan baik dalam memori atau di penyimpanan Lokal atau Sesi pada klien.
Paul

1
@ Paul tentang penyimpanan lokal. Itu tergantung pada klien. Tidak semua klien dan tidak semua versi klien yang paling banyak digunakan mendukung penyimpanan web. Coba lihat di sini . Jika ya, lebih baik membuat token musiman . Tetapi, jika klien kami tidak mendukung penyimpanan lokal; Cookie Httponly + SSL + client fingerPrints memberi kami implementasi yang cukup aman.
Laiv

@Laiv saya tidak setuju dengan Anda; Hanya saja Samuel mengatakan bahwa "Token itu disimpan dalam cookie", dan saya hanya berusaha mengamati bahwa ini tidak selalu terjadi.
Paul

@ Paul saya berubah menjadi membaca "... dapat disimpan dalam cookie"
Samuel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.