Saya membaca beberapa posting tentang "JWT vs Cookie" tetapi itu hanya membuat saya semakin bingung ...

1. Saya ingin klarifikasi , ketika orang berbicara tentang "otentikasi berbasis token vs cookie", cookie di sini hanya merujuk ke cookie sesi ? Pemahaman saya adalah bahwa cookie itu seperti media , dapat digunakan untuk mengimplementasikan otentikasi berbasis token (menyimpan sesuatu yang dapat mengidentifikasi pengguna yang masuk di sisi klien ) atau otentikasi berbasis sesi (menyimpan konstanta di sisi klien yang cocok dengan informasi sesi di sisi server )

2. Mengapa kita membutuhkan token web JSON ? Saya menggunakan cookie standar untuk menerapkan otentikasi berbasis token ( tidak menggunakan id sesi, tidak menggunakan memori server atau penyimpanan file ) :,Set-Cookie: user=innocent; preferred-color=azure dan satu-satunya perbedaan yang saya amati adalah bahwa JWT berisi muatan dan tanda tangan ... sedangkan Anda dapat memilih antara cookie bertanda tangan atau teks biasa untuk header http. Menurut pendapat saya, cookie yang ditandatangani ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') lebih hemat ruang, satu-satunya kelemahan adalah klien tidak dapat membaca token, hanya server yang bisa ... tetapi saya pikir tidak apa-apa karena seperti klaim di JWT bersifat opsional, tidak perlu token untuk menjadi bermakna

Perbedaan terbesar antara token pembawa dan cookie adalah browser akan secara otomatis mengirim cookie , di mana token pembawa perlu ditambahkan secara eksplisit ke permintaan HTTP.

Fitur ini menjadikan cookie sebagai cara yang baik untuk mengamankan situs web, tempat pengguna masuk dan menavigasi antar halaman menggunakan tautan.

Browser yang secara otomatis mengirimkan cookie juga memiliki kerugian besar, yaitu CSRF serangan . Dalam serangan CSRF, situs web jahat memanfaatkan fakta bahwa browser Anda akan secara otomatis melampirkan cookie otentikasi ke permintaan ke domain itu dan menipu browser Anda untuk menjalankan permintaan.

Misalkan situs web di https://www.example.com memungkinkan pengguna yang diautentikasi untuk mengubah kata sandi mereka dengan- POSTmemasukkan kata sandi baru ke https://www.example.com/changepassword tanpa memerlukan nama pengguna atau kata sandi lama untuk diposting.

Jika Anda masih masuk ke situs web tersebut saat mengunjungi situs web berbahaya yang memuat halaman di browser Anda yang memicu POST ke alamat itu, browser Anda akan dengan setia melampirkan cookie otentikasi, memungkinkan penyerang untuk mengubah kata sandi Anda.

Cookie juga dapat digunakan untuk melindungi layanan web, tetapi token pembawa saat ini paling sering digunakan. Jika Anda menggunakan cookie untuk melindungi layanan web Anda, layanan tersebut harus aktif di domain tempat cookie autentikasi disetel, karena kebijakan asal yang sama tidak akan mengirim cookie ke domain lain.

Selain itu, cookie mempersulit aplikasi berbasis non-browser (seperti aplikasi seluler ke tablet) untuk menggunakan API Anda.

Gambaran

Apa yang Anda minta adalah perbedaan antara cookie dan token pembawa untuk mengirim Token Web JSON (JWT) dari klien ke server.

Cookie dan token pembawa mengirim data.

Satu perbedaan adalah cookie untuk mengirim dan menyimpan data arbitrer, sedangkan token pembawa khusus untuk mengirim data otorisasi.

Data tersebut sering kali dikodekan sebagai JWT.

Kue kering

Cookie adalah pasangan nama-nilai, yang disimpan di browser web, dan memiliki tanggal kedaluwarsa serta domain terkait.

Kami menyimpan cookie di browser web baik dengan JavaScript atau dengan header Respon HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Browser web secara otomatis mengirimkan cookie dengan setiap permintaan ke domain cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Token Pembawa

Token pembawa adalah nilai yang masuk ke Authorizationheader Permintaan HTTP apa pun. Itu tidak disimpan secara otomatis di mana pun, tidak memiliki tanggal kedaluwarsa, dan tidak ada domain terkait. Itu hanya sebuah nilai. Kami menyimpan nilai tersebut secara manual di klien kami dan secara manual menambahkan nilai tersebut ke header HTTP Authorization.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT dan Otentikasi Berbasis Token

Saat kami melakukan autentikasi berbasis token, seperti OpenID, OAuth, atau OpenID Connect, kami menerima access_token (dan terkadang id_token) dari otoritas tepercaya. Biasanya kami ingin menyimpannya dan mengirimkannya bersama dengan Permintaan HTTP untuk sumber daya yang dilindungi. Bagaimana kita melakukannya?

Opsi 1 adalah menyimpan token dalam cookie. Ini menangani penyimpanan dan juga secara otomatis mengirimkan token ke server di Cookieheader setiap permintaan. Server kemudian mengurai cookie, memeriksa token, dan merespons sesuai.

Opsi lainnya adalah menyimpan token di penyimpanan lokal / sesi, lalu mengatur Authorizationheader setiap permintaan secara manual . Dalam kasus ini, server membaca header dan melanjutkan seperti cookie.

Ada baiknya membaca RFC yang ditautkan untuk mempelajari lebih lanjut.

Selain apa yang dikatakan MvdD tentang cookie yang dikirim secara otomatis:

1. Cookie bisa menjadi media, tetapi fungsi terpentingnya adalah bagaimana ia berinteraksi dengan browser. Cookie ditetapkan oleh server dan dikirim dalam permintaan dengan cara yang sangat spesifik. JWT di sisi lain secara eksklusif adalah media, itu adalah penegasan dari beberapa fakta dalam struktur tertentu. Jika Anda sangat ingin, Anda dapat menempatkan JWT sebagai cookie otentikasi Anda. Saat Anda membaca artikel yang membandingkannya, mereka biasanya membicarakan tentang penggunaan JWT yang dikirim sebagai token pembawa dengan kode ujung depan vs cookie autentikasi yang sesuai dengan beberapa sesi cache atau data pengguna di bagian belakang.
2. JWT menawarkan banyak fitur, dan menempatkannya dalam standar sehingga dapat digunakan di antara pesta. JWT dapat bertindak sebagai pernyataan yang ditandatangani dari beberapa fakta di banyak tempat berbeda. Cookie, tidak peduli data apa yang Anda masukkan atau jika Anda menandatanganinya, hanya benar-benar masuk akal untuk digunakan antara browser dan back end tertentu. JWT dapat digunakan dari browser ke back end, antara back end yang dikendalikan oleh pihak yang berbeda (OpenId Connect adalah contoh), atau dalam layanan back end dari satu pihak. Mengenai contoh spesifik Anda dari cookie yang ditandatangani, Anda mungkin dapat mencapai fungsi yang sama ("tidak menggunakan id sesi, tidak menggunakan memori server atau penyimpanan file") seperti JWT dalam kasus penggunaan itu, tetapi Anda kehilangan pustaka dan tinjauan sejawat dari standar, selain masalah CSRF yang dibicarakan di jawaban lain.

Singkatnya: posting yang Anda baca mungkin membandingkan JWT sebagai token pembawa dengan cookie otentikasi untuk tujuan otentikasi browser ke server. Tetapi JWT dapat melakukan lebih banyak lagi, ia menghadirkan standardisasi dan fitur untuk digunakan di luar kasus penggunaan yang mungkin Anda pikirkan.

Meskipun cookie dapat meningkatkan risiko serangan CSRF karena dikirim secara otomatis bersama dengan permintaan, cookie dapat mengurangi risiko serangan XSS saat HttpOnlybendera disetel, karena skrip apa pun yang disuntikkan ke halaman tidak akan dapat membaca kue.

CSRF: pengguna mengklik link (atau melihat gambar) di situs penyerang, yang menyebabkan browser mengirimkan permintaan ke situs korban. Jika korban menggunakan cookie, browser secara otomatis akan memasukkan cookie dalam permintaan, dan jika permintaan GET dapat menyebabkan tindakan non-read-only, situs korban rentan terhadap serangan tersebut.

XSS: penyerang menyematkan skrip di situs korban (situs korban hanya rentan jika masukan tidak dibersihkan dengan benar), dan skrip penyerang dapat melakukan apa pun yang diizinkan untuk dilakukan javascript di halaman. Jika Anda menyimpan token JWT di penyimpanan lokal, skrip penyerang dapat membaca token tersebut, dan juga mengirim token tersebut ke server yang mereka kontrol. Jika Anda menggunakan cookie dengan HttpOnlybendera, skrip penyerang tidak akan dapat membaca cookie Anda sejak awal. Meskipun demikian, skrip yang berhasil mereka masukkan akan tetap dapat melakukan apa pun yang dapat dilakukan javascript, jadi Anda masih menyemprot IMO (yaitu, meskipun mereka mungkin tidak dapat membaca cookie untuk mengirimkannya ke server mereka sendiri untuk digunakan nanti , mereka dapat mengirim permintaan ke situs vicitim menggunakan XHR, yang akan tetap menyertakan cookie).

Ref - Kebutuhan Token Web JSON

Kue

Untuk cookie, setelah pengguna diautentikasi, maka Server Gmail akan membuat ID sesi unik. Sesuai dengan id sesi ini, ia akan menyimpan di memori semua informasi pengguna yang dibutuhkan oleh server Gmail untuk mengenali pengguna dan memungkinkannya melakukan operasi.
Selain itu, untuk semua permintaan dan respons berikutnya, id sesi ini juga akan diteruskan. Jadi sekarang ketika server menerima permintaan itu akan memeriksa id sesi. Menggunakan id sesi ini akan memeriksa apakah ada informasi yang sesuai. Ini kemudian akan memungkinkan pengguna untuk mengakses sumber daya dan mengembalikan respons bersama dengan id sesi.

Kekurangan Cookies

• Cookies / session id tidak berdiri sendiri. Ini adalah token referensi. Selama setiap validasi, server Gmail perlu mengambil informasi yang sesuai dengannya.
• Tidak cocok untuk arsitektur layanan mikro yang melibatkan beberapa API dan server

JWT

• JWT itu mandiri. Ini adalah token nilai. Jadi selama setiap validasi, server Gmail tidak perlu mengambil informasi yang sesuai dengannya.
• Itu ditandatangani secara digital jadi jika ada yang memodifikasinya, server akan mengetahuinya
• Ini paling cocok untuk Arsitektur Layanan Mikro
• Ini memiliki keuntungan lain seperti menentukan waktu kedaluwarsa.