Learn-json-web-tokens: Informasi berbahaya dan salah di README

Beberapa yang dipikirkan dengan sangat baik dan dengan jelas mengungkapkan kekhawatiran yang tentu saja memberi saya beberapa bahan untuk dipikirkan sebagai seseorang yang baru saja mulai melihat repo. Saya sedang mencari contoh cepat untuk membuat contoh kerja auth JWT dengan Node.js. Ketertarikan saya pada JWT adalah untuk memberikan pendekatan praktik terbaik modern untuk manajemen sesi untuk REST API dan klien js sambil menghindari masalah CORS. Saya agak tertarik pada keamanan tetapi ini bukan motivasi saya untuk menggunakan JWT meskipun saya menghargai peran yang dapat dimainkan token dalam pendekatan aman yang lebih komprehensif seperti OAUTH. Ketika saya pertama kali membaca repo ini, saya terkejut karena menyertakan banyak catatan yang telah dikumpulkan oleh penulis karena mereka membangun pengetahuan mereka tentang penggunaan JWT, dll. Meskipun saya memiliki sedikit investasi dalam repo ini, saya cenderung percaya bahwa ada tempat untuk platform spesifik, contoh kerja minimalis login/logout dengan beberapa alat pendukung, referensi. Sebagai dasar untuk keterampilan on-boarding dan sebagai starter, saya pikir tujuan repo ini bagus, tetapi mungkin README memang membutuhkan penulisan ulang yang serius dan fokus ulang pada tujuan penggunaan jenis JWT ini. Saya akan dengan senang hati mencoba menyarankan sesuatu .. joepie91 - Anda jelas memiliki pemahaman yang baik tentang masalah ini .. dapatkah Anda memberikan beberapa pemikiran tentang apa manfaat sebenarnya dari penggunaan JWT semacam ini?

Hai @joepie91 , kami _stoked_ bahwa Anda telah menemukan dan _membaca_ catatan kami di JWT!
terima kasih telah meluangkan waktu untuk membuka masalah ini untuk menyampaikan kekhawatiran Anda. ❤️
Kami akan _ senang_ jika Anda membagi setiap masalah Anda menjadi masalah _terpisah_ atau setidaknya memberi nomor agar lebih mudah untuk didiskusikan.

Kami _dengan hormat_ tidak setuju bahwa isi catatan ini adalah "_Berbahaya_".

_Cookies _ > dalam The EU ePrivacy directive Recital 25 , cookies _disebutkan secara eksplisit _ 5 kali:

Lihat:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
atau:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX :32002L0058:EN:HTML

Memang, _banyak_ situs web/aplikasi (_yang tidak menggunakan cookie pelacakan pihak ketiga_) termasuk dalam ‘strictly necessary for the delivery of a service requested by the user’ ... itulah sebabnya kami _menggunakan_ cookie dalam aplikasi web _yang ditingkatkan secara progresif_. lihat: https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

Menyimpan JWT di _localStorage _ > Sementara kami _setuju_ bahwa menyimpan data sesi/token di localStorage berarti JavaScript _diperlukan _ (_kami juga tidak menyukai ini, kami lebih memilih peningkatan progresif , ini dimaksudkan untuk mencatat opsi alternatif ..._). localStorage adalah bagaimana _semua _ aplikasi yang dibangun dengan "_Backend-as-a-Service_" dibuat, karena BaaS biasanya tidak menerima cookie... Apakah Anda menyarankan bahwa setengah juta pengembang yang menggunakan Google Firebase melakukan itu "_salah_"...? (_ini akan menjadi diskusi yang bagus - terpisah -...!_)

Sesi Stateless _mungkin_ dengan JWT karena mereka memiliki opsi exp (_expiration time_) bawaan, namun kami _memilih/memilih_ _tidak _ untuk membuat sesi kami stateless alih-alih memilih untuk menyimpan id sesi ( jti ) _inside_ JWT yang dicari di toko Redis _after_ JWT telah diverifikasi. Ini berarti kita dapat _membatalkan _ sesi ketika seseorang keluar atau jika perangkat mereka dicuri dan mereka perlu mencabut sesi aktif.

Ya, tujuan _primary_ JWT adalah untuk pass claims between parties in web application environment , itulah _persis_ apa yang kami gunakan untuk itu.

Id atau token sesi kami _bisa_ hanya berupa string acak yang diperiksa di sisi server, tetapi kami _memutuskan_ untuk menggunakan JWT untuk _format_ dan _menandatangani_ data sesi.

Kesimpulan: mari perbarui readme ke _clarify_ things. 👍

Daripada membagi masalah yang diangkat menjadi serangkaian masalah seperti yang disarankan oleh @nelsonic, saya cenderung setuju bahwa maksud dan tujuan implementasi harus diklarifikasi dalam ruang lingkup README. Saya tidak membaca isu @joepie91 sebagai kritik terhadap penggunaan JWT dalam konteks aplikasi web seperti itu, atau dukungan cookie sebagai superior; melainkan saya mengambil kritik sebagai bahwa deskripsi JWT disajikan dengan cara yang berlebihan atau salah mengartikan alasan memilih JWT.
Kekhawatiran yang sama diungkapkan juga di #55(jelaskan bahwa JWT bukan enkripsi ...)

Bagi saya cukup untuk dapat mengoperasikan Firebase dan layanan saya sendiri menggunakan klaim umum yang kedaluwarsa. Saya dapat memperluasnya untuk memasukkan beberapa keadaan dalam beberapa kasus dan tidak pada yang lain dan masih lebih suka pendekatan untuk menggunakan cookie atau pendekatan otentikasi http kontrol akses yang lebih lama.
Saya suka bahwa saya dapat menggunakan token JWT sebagai bagian dari pendekatan yang lebih canggih tetapi saya masih setuju bahwa fokus pada manfaat README harus pada masalah yang ingin kita selesaikan dengan mereka daripada menyimpang ke dasar yang kurang solid. Sebagian besar bahan referensi dalam README mungkin dapat diturunkan ke catatan atau bahkan Wiki sebagai bahan diskusi?

Saya tidak tahu apakah saya harus mengatakan bahwa README berbahaya - tampaknya sedikit kuat

Cookie > dalam Resital 25 direktif ePrivacy EU, cookie disebutkan secara eksplisit sebanyak 5 kali:

Maaf, sepertinya saya mengatakannya dengan agak samar. Meskipun teks tersebut mengandung kata "cookie" di beberapa tempat, teks tersebut tidak mengidentifikasinya sebagai konsep khusus yang akan diundangkan; alih-alih, ini diberikan sebagai contoh (dan dengan demikian sisa poin saya tetap berlaku, dan "tidak menggunakan cookie" tidak akan secara ajaib menghilangkan kebutuhan akan persetujuan).

localStorage adalah bagaimana semua aplikasi yang dibangun dengan "Backend-as-a-Service" dibuat, karena BaaS biasanya tidak menerima cookie...

Ini tidak relevan, dan masalah layanan tersebut. Itu _not_ membenarkan penggunaan JWT untuk sesi di aplikasi Anda sendiri.

Apakah Anda menyarankan bahwa setengah juta pengembang yang menggunakan Google Firebase melakukannya dengan "salah"...?

Selain fakta bahwa Firebase direkayasa dengan sangat buruk, ini merupakan banding ke otoritas dan tidak memiliki tempat dalam diskusi teknis. Saya tidak tertarik membahas keputusan perusahaan tertentu untuk produk tertentu; Saya hanya tertarik untuk membahas kelebihan dan kekurangan dari pendekatan yang diberikan.

Sesi Stateless dimungkinkan dengan JWT karena mereka memiliki opsi exp (waktu kedaluwarsa) bawaan, namun kami memilih/memilih untuk tidak membuat sesi kami stateless daripada memilih untuk menyimpan id sesi (jti) di dalam JWT yang akan dicari di a Toko Redis setelah JWT diverifikasi. Ini berarti kami dapat membatalkan sesi ketika seseorang keluar atau jika perangkat mereka dicuri dan mereka perlu mencabut sesi aktif.

Pada titik mana tidak ada manfaat sebenarnya untuk menggunakan JWT lagi. Mengapa Anda tidak menggunakan express-session atau solusi sesi peer-review yang telah teruji pertempuran lainnya yang sesuai dengan tumpukan Anda? Rekomendasi untuk JWT tidak masuk akal di sini, karena orang _seharusnya tidak menggulirkan manajemen sesi mereka sendiri sejak awal_.

Belum lagi kedaluwarsa sesi harus ditangani _server-side_, sehingga exp di JWT Anda pada dasarnya tidak berguna.

Ya, tujuan utama JWT adalah untuk menyampaikan klaim antara pihak-pihak di lingkungan aplikasi web, untuk itulah kami menggunakannya.

JWT tidak terkait dengan "lingkungan aplikasi web" sedikit pun.

ID atau token sesi kami dapat berupa string acak yang diperiksa di sisi server, tetapi kami memutuskan untuk menggunakan JWT untuk memformat dan menandatangani data sesi.

Sekali lagi, cukup gunakan implementasi sesi yang telah teruji pertempuran untuk tumpukan Anda. JWT adalah rekomendasi yang salah untuk dibuat di sini.

Kami dengan hormat tidak setuju bahwa isi dari catatan ini adalah "Berbahaya".

Anda boleh tidak setuju, tapi begitulah adanya. Ada begitu banyak cara untuk menggunakan JWT yang salah - beberapa di antaranya disinggung oleh README di repositori ini - sehingga orang _terikat_ untuk menembak kaki mereka sendiri. Ya, itu berbahaya.

@pscott-au: joepie91 - Anda jelas memiliki pemahaman yang baik tentang masalah ini .. dapatkah Anda memberikan beberapa pemikiran tentang apa manfaat sebenarnya dari penggunaan JWT semacam ini?

Tidak ada manfaat menggunakan JWT untuk aplikasi web standar, kecuali jika Anda menjalankan pada skala Reddit. Beberapa contoh umum kasus di mana JWTs _are_ berguna:

• Mekanisme Single Sign-On (di mana JWT digunakan sebagai token autentikasi satu kali yang ditukarkan pengguna untuk sesi dalam aplikasi target),
• Token akses sementara untuk gambar pribadi di mana URL dimaksudkan untuk dapat dibagikan,
• Pada dasarnya skenario apa pun di mana dua sistem yang saling percaya perlu bertukar sedikit data melalui pihak yang tidak dipercaya, tanpa bersentuhan langsung satu sama lain atau berbagi backend.

Untuk sesi aplikasi web standar, Anda sebaiknya menggunakan implementasi sesi yang telah teruji dengan baik untuk tumpukan apa pun yang Anda gunakan (mis. express-session saat Anda menggunakan Express).

Sangat menyenangkan untuk memiliki diskusi ini karena benar-benar menantang beberapa pengalaman saya. Mungkin beberapa konteks untuk minat pribadi saya dalam menggunakan JWT (selain dari fakta bahwa saya menggunakan Firebase yang saya akan tertarik untuk mempelajari masalah teknik yang buruk yang akan saya lihat). Saat membuat aplikasi seluler/SPA dan terutama saat menggunakan layanan yang bersumber dari beberapa server/domain, saya menemukan bahwa saya sering memerlukan kemampuan masuk tunggal yang tampaknya cocok dengan JWT. Pemahaman saya adalah bahwa penggunaan cookie sesi berkembang selama periode di mana keamanan diperketat di browser dan ruang JS dan pengenalan CORS berevolusi untuk menangani pengecualian untuk ini meninggalkan kami dengan solusi yang agak retas yang JWT lakukan untuk mengatasi .
Selama bertahun-tahun pendekatan sesi cookie telah memberikan pendekatan yang jauh lebih baik daripada dasar asli dan intisari http auth dan ada banyak waktu ketika saya akan menggunakan solusi manajemen sesi cookie untuk aplikasi berbasis web.
Tapi .. Saya menemukan bahwa sebagian besar aplikasi yang saya buat sekarang adalah seluler atau SPA dan banyak menggunakan REST APIS. Saya suka dapat menguji dengan mudah dengan permintaan ikal sederhana tanpa menggabungkan hal-hal yang menangani cookie atau berurusan dengan banyak permintaan untuk membuat sesi. Jadi saya menemukan bahwa mengimplementasikan API dengan cepat sehingga semuanya berfungsi ketika saya menggunakan JWT. Dalam perut saya rasanya lebih tepat menggunakan JWT untuk sesi yang berjalan lama daripada cookie meskipun saya akan merenungkan ini karena mungkin kemalasan lebih dari intuisi yang baik. Saya dapat memperluas keamanan di sepanjang garis OAUTH jika perlu dan saya ingin mengamankan hal-hal lebih menyeluruh tetapi lebih sering daripada tidak, sesi bukanlah sesuatu yang saya nilai membutuhkan tingkat keamanan ini. Yang penting bagi saya adalah fleksibilitas yang ditawarkan oleh pendekatan otentikasi berbasis JWT sehubungan dengan perubahan arsitektur di masa depan. Saya telah menemukan bahwa kode yang lebih lama telah di-refactored untuk memberikan auth JWT sebagai opsi dan ini secara mengejutkan memperkenalkan sedikit kompleksitas pemeliharaan tetapi dalam banyak kasus menyederhanakan pengembangan di masa depan dan saya tidak melihat bagian mana pun darinya secara inheren lebih rendah daripada sesi cookie.
Sebenarnya ada keuntungan menggunakan fitur batas waktu JWT, terutama pada perangkat seluler dan beberapa pustaka pendukung memanfaatkan ini. Misalnya, Anda dapat meminta aplikasi mengeluarkan pengguna atau membiarkan mereka masuk berdasarkan batas waktu ini saat perangkat tidak terhubung ke jaringan.
Bagi saya, saya tidak begitu banyak melihat argumen yang meyakinkan tentang keuntungan skala JWT dibandingkan cookie sesi.
Saya melihat orang-orang menyarankan bahwa JWT dapat digunakan sebagai cookie sesi yang bagi saya lebih berbahaya daripada kebaikan karena cookie memiliki periode waktu tunggu sendiri (tidak sepenuhnya dikelola sisi server) dan menggabungkan ini cenderung membingungkan.
Banyak kerangka kerja JS modern memberikan dukungan yang lebih besar untuk JWT daripada cookie yang menunjukkan bahwa pertempuran yang diuji solusi peer-review untuk tumpukan mungkin sebenarnya cenderung ke arah JWT untuk banyak aplikasi. Sementara popularitas JWT untuk layanan web bukanlah argumen teknis, menganggap ini tidak relevan karena semuanya sama-sama keliru. Express bukan elemen inti tumpukan yang digunakan oleh grup dwyl sebaik yang saya tahu sehingga tidak ada alasan untuk menyelaraskannya.
Saya harap ada beberapa maksud saya yang dapat Anda setujui karena saya tetap prihatin tetapi tidak sepenuhnya yakin dengan argumen Anda.
Saya setuju bahwa README membutuhkan perbaikan serius dan bahwa ada baris yang lebih baik dihapus atau didorong kembali ke teks diskusi latar belakang dan bukan di README utama.

(selain fakta bahwa saya menggunakan Firebase yang saya akan tertarik untuk mempelajari masalah teknik yang buruk yang akan saya lihat)

Beberapa masalah adalah bahwa pustaka klien JS-nya adalah sumber tertutup dan dikaburkan dengan keluaran kesalahan yang agak tidak membantu, tidak ada yang namanya "array", ada banyak bug aneh di pustaka klien di mana Anda mungkin tidak mendapatkan kembali tanggapan untuk alasan yang tidak jelas, sistem ACL menggunakan varian JSON non-standar yang bahkan editornya sendiri tidak mendukung, JS API perlu menggunakan API peristiwa semu daripada API panggilan balik normal (tetapi tidak berperilaku secara konsisten), dan segera.

Saat membuat aplikasi seluler/SPA dan terutama saat menggunakan layanan yang bersumber dari beberapa server/domain, saya menemukan bahwa saya sering memerlukan kemampuan masuk tunggal yang tampaknya cocok dengan JWT. Pemahaman saya adalah bahwa penggunaan cookie sesi berkembang selama periode di mana keamanan diperketat di browser dan ruang JS dan pengenalan CORS berevolusi untuk menangani pengecualian untuk ini meninggalkan kami dengan solusi yang agak retas yang JWT lakukan untuk mengatasi .

Tidak cukup akurat. Aplikasi Anda dan API pihak ketiga adalah hal yang berbeda, dengan persyaratan autentikasi yang berbeda. Sementara sistem otentikasi berbasis token bisa masuk akal dalam aplikasi saat berbicara dengan API pihak ketiga, ini tidak masuk akal untuk aplikasi Anda sendiri, bahkan jika itu adalah SPA. Itu juga tidak terkait dengan "single sign-on", yang mengacu pada beberapa layanan pengguna akhir menggunakan layanan login yang sama.

CORS adalah masalah yang terpisah, dan tidak terlalu terkait dengan ini.

Tapi .. Saya menemukan bahwa sebagian besar aplikasi yang saya buat sekarang adalah seluler atau SPA dan banyak menggunakan REST APIS. Saya suka dapat menguji dengan mudah dengan permintaan ikal sederhana tanpa menggabungkan hal-hal yang menangani cookie atau berurusan dengan banyak permintaan untuk membuat sesi. Jadi saya menemukan bahwa mengimplementasikan API dengan cepat sehingga semuanya berfungsi ketika saya menggunakan JWT.

Dalam pengembangan, Anda mungkin memiliki persyaratan pengujian tertentu, tetapi ini seharusnya tidak memengaruhi pendekatan yang Anda ambil dalam produksi. Selain fakta bahwa sebagian besar hal yang merupakan SPA seharusnya tidak menjadi SPA untuk memulai (SPA adalah untuk aplikasi web, bukan situs web!), Tidak ada alasan mengapa Anda tidak dapat menggunakan sesi dengannya.

Selain itu, cURL mendukung cookie dengan baik, dan ada banyak klien pengujian API lain yang lebih baik seperti httpie atau bahkan http-Prompt .

Saya dapat memperluas keamanan di sepanjang garis OAUTH jika perlu dan saya ingin mengamankan hal-hal lebih menyeluruh tetapi lebih sering daripada tidak, sesi bukanlah sesuatu yang saya nilai membutuhkan tingkat keamanan ini.

Sesi adalah salah satu aspek terpenting dari aplikasi Anda. Jika tidak cukup aman, aplikasi Anda pada dasarnya rusak dan sangat rentan. Itu sebabnya misalnya. menyimpan JWT di LocalStorage adalah ide yang buruk.

Yang penting bagi saya adalah fleksibilitas yang ditawarkan oleh pendekatan otentikasi berbasis JWT sehubungan dengan perubahan arsitektur di masa depan. Saya telah menemukan bahwa kode yang lebih lama telah di-refactored untuk memberikan auth JWT sebagai opsi dan ini secara mengejutkan memperkenalkan sedikit kompleksitas pemeliharaan tetapi dalam banyak kasus menyederhanakan pengembangan di masa depan dan saya tidak melihat bagian mana pun darinya secara inheren lebih rendah daripada sesi cookie.

Tidak ada fleksibilitas yang diperkenalkan di sini yang dibutuhkan oleh 99,99% pengembang, dan saya telah menyoroti beberapa masalah yang ditimbulkannya, seperti data basi dan ketidakmampuan untuk membatalkan token.

Sebenarnya ada keuntungan menggunakan fitur batas waktu JWT, terutama pada perangkat seluler dan beberapa pustaka pendukung memanfaatkan ini. Misalnya, Anda dapat meminta aplikasi mengeluarkan pengguna atau membiarkan mereka masuk berdasarkan batas waktu ini saat perangkat tidak terhubung ke jaringan.

Ini tidak unik untuk JWT; Anda dapat melakukan ini dengan sesi sisi server dengan baik. Faktanya, JWT tidak dapat dibatalkan tanpa memperkenalkan arsitektur stateful (kompleks), jadi sesi benar-benar menang di sini.

Bagi saya, saya tidak begitu banyak melihat argumen yang meyakinkan tentang keuntungan skala JWT dibandingkan cookie sesi.

Keuntungan penskalaan adalah Anda tidak memerlukan satu server kanonik yang menampung semua sesi (karena data dapat disimpan langsung di token), artinya Anda dapat menghilangkan hambatan. Tetapi seperti yang saya katakan, hampir tidak ada pengembang yang akan mengalami masalah ini dalam praktiknya. Ini hanya berguna untuk proyek berskala sangat besar.

Banyak kerangka kerja JS modern memberikan dukungan yang lebih besar untuk JWT daripada cookie yang menunjukkan bahwa pertempuran yang diuji solusi peer-review untuk tumpukan mungkin sebenarnya cenderung ke arah JWT untuk banyak aplikasi.

Saya belum melihat kerangka kerja yang tidak mendukung cookie sesi.

Express bukan elemen inti tumpukan yang digunakan oleh grup dwyl sebaik yang saya tahu sehingga tidak ada alasan untuk menyelaraskannya.

Itu adalah masalah mereka. Express hanyalah salah satu contoh, implementasi sesi yang telah teruji pada dasarnya ada untuk setiap kerangka kerja yang umum digunakan.

Intinya adalah bahwa untuk setiap pengembang yang membaca repositori ini, tidak akan ada keuntungan nyata dari JWT, dan beberapa kelemahan atau bahkan masalah keamanan. Ini bukan pilihan atau rekomendasi teknis yang baik, dan itu benar-benar akhirnya.

@joepie91 Saya tidak dapat memberi tahu Anda betapa senangnya saya karena Anda telah menemukan repo/catatan kami dan menginvestasikan waktu Anda untuk membacanya dan memberi kami umpan balik! Serius, jika saya bertemu Anda secara langsung, saya akan memberi Anda _pallet_ apa pun yang ingin Anda minum! 🍺

Jika saya menjadikan Anda kontributor pada repo ini, apakah Anda akan meninjau Permintaan Tarik saya untuk _meningkatkan_nya? 📝

Juga, @AshleyPinner , @alfiepates , @sunny-g bagaimana _you_ gentlemen menemukan diskusi _particular_ ini? apakah masalah tersebut dibagikan di Redit/Hackernews? (_Saya hanya ingin tahu bagaimana orang menemukan postingan kami..._)

Saya telah mengunyah ini selama beberapa hari dan tidak dapat menerima banyak argumen yang menentang penggunaan JWT sebagai pilihan default sebelum cookie sesi tradisional di SPA modern dan aplikasi seluler.
Saya sedang berpikir untuk membuat matriks keputusan untuk menimbang pro dan kontra pendekatan auth cookie/JWT untuk persyaratan tertentu, atau merinci pro dan kontra di serangkaian kasus penggunaan sebelum berpikir tentang menulis ulang README. Tampaknya bagi saya bahwa banyak tantangan dunia nyata yang dihadapi orang dalam membangun aplikasi kompleks sebagian besar diselesaikan dengan kurang elegan atau setidaknya sama bermasalahnya dengan menggunakan sesi cookie. Persepsi yang dibuat oleh pembuat poster masalah adalah bahwa JWT adalah beberapa teknologi yang belum matang dan tidak dapat diandalkan yang diretas bersama yang tidak cocok untuk aplikasi modern dan pernyataan ini mungkin bahkan lebih berbahaya daripada memberikan contoh penggunaan yang berfungsi penuh untuk mengautentikasi pengguna.
Saya menemukan artikel OATH ini bermanfaat . Saya pikir salah satu hal yang memicu reaksi keras terhadap repo ini tetapi reporter masalah adalah diskusi tentang fitur yang biasanya diharapkan dalam Sesi Cookie menggunakan JWT yang mengurangi beberapa manfaat inti JWT, terutama yang melibatkannya bisa tanpa kewarganegaraan. Memperkenalkan status dengan memasukkan penyimpanan persisten, kami menghilangkan salah satu kasus penggunaan utama untuk JWT dan mengimplementasikan kembali hal-hal yang matang menggunakan cookie.
Meskipun demikian, aplikasi kompleks cenderung memerlukan beberapa status pencarian - bahkan jika hanya untuk permintaan transaksional untuk tindakan yang diproses di luar masa pakai satu permintaan HTTP. Ini seharusnya tidak menghalangi penggunaan JWT tetapi harus memberi kita jeda untuk mempertimbangkan peran apa yang dimainkan JWT dalam transaksi. Saya menganggap OK untuk memiliki JWT yang memberikan akses ke sumber daya dan sumber daya memiliki status untuk pengguna yang menolak akses ke layanan; dalam hal ini bukan JWT yang harus kadaluarsa, tetapi status pengguna yang mengakses layanan menggunakan JWT.

Memperluas lebih jauh untuk menggunakan cookie sebagai mekanisme transportasi menghilangkan manfaat lain dan membawa kita kembali menggunakan cookie tetapi mengabaikan fungsionalitas perpustakaan yang biasa dan fitur penulisan ulang dari awal yang memperkenalkan ambiguitas lebih lanjut karena kita berakhir dengan waktu tunggu duplikat dll. Ketika saya menyebutkan CORS sebelumnya mungkin lebih baik secara eksplisit menunjukkan kesulitan menggunakan banyak domain dengan cookie. Tentu, Anda dapat mengatur domain wildcard, tetapi jika mereka cukup berbeda maka cookie sesi tradisional dengan cepat menjadi berat. Dapat dikatakan bahwa sebagian besar pengembang tidak memerlukan klien terotentikasi mereka untuk mengakses sumber daya yang dilindungi di banyak domain, tetapi ini menjadi jauh lebih praktik umum daripada kasus tepi yang eksotis.
Dalam arti sebagai orang baru yang mulai menjelajahi pengelolaan sesi yang diautentikasi, saya menghargai bahwa ini mungkin bukan cara yang tepat untuk mempelajari tentang cara membatasi akses ke sumber daya dalam aplikasi web untuk pengguna yang diautentikasi dalam pengertian yang paling sederhana, tetapi penggunaan JWT hanya akan menjadi lebih menonjol sebagai titik awal untuk sesi yang diautentikasi sehingga mengabaikan ini karena kami telah menggunakan cookie sesi untuk waktu yang lama tidak cukup bagi saya untuk percaya bahwa setiap orang harus memulai dengan cookie sesi dan hanya mempelajari dan menggunakan JWT ketika mereka menemukan bahwa mereka tidak dapat membagikan cookie di seluruh domain atau perlu mengakses API pihak ke-3 atau harus dapat menentukan kedaluwarsa tanpa memeriksa server, atau mempertanyakan penyimpanan kredensial login pengguna di perangkat seluler, dll, dll. .

Mengecilkan keuntungan dari token stateless sebagai sesuatu yang tidak relevan kecuali Anda menjalankan situs perdagangan tingkat atas adalah tidak benar. Bahkan ketika kami menyelesaikan masalah dengan memperkenalkan lapisan status baru, pemisahan sesi dari server memiliki banyak keuntungan.

@nelsonic Melihat 4744cd1bb8991bc4057c749f86007fcecac19d1d, itu sepertinya kata-kata yang jauh lebih jelas. Namun, header tampaknya tidak mencerminkan perubahan.

@pscott-au: di SPA modern dan aplikasi seluler.

Ini _sepenuhnya_ ortogonal dengan mekanisme sesi pilihan Anda. Belum lagi sebagian besar hal yang merupakan SPA hari ini, seharusnya tidak. Menggunakan SPA untuk situs web (sebagai lawan dari aplikasi web) merusak web.

Tampaknya bagi saya bahwa banyak tantangan dunia nyata yang dihadapi orang dalam membangun aplikasi kompleks sebagian besar diselesaikan dengan kurang elegan atau setidaknya sama bermasalahnya dengan menggunakan sesi cookie.

Seperti?

Persepsi yang dibuat oleh poster masalah adalah bahwa JWT adalah teknologi yang belum matang yang tidak dapat diandalkan yang tidak cocok untuk aplikasi modern yang diretas bersama.

Tidak. JWT sebagai teknologi tidak buruk (bahkan jika ada _are_ beberapa keputusan yang dipertanyakan dalam spesifikasi) - sesi bukan tujuan yang dimaksudkan, dan itu tidak cocok untuk usecase itu.

Saya tidak mengatakan bahwa alat itu buruk, saya mengatakan bahwa Anda salah menggunakannya.

dan pernyataan ini mungkin bahkan lebih berbahaya daripada

Apa alasan Anda untuk itu?

Saya menemukan artikel OATH ini bermanfaat.

Mengatasinya poin demi poin:

• Stateless, Scalable, dan Decoupled: Saya telah mengakui bahwa ini adalah manfaat teoretis, tetapi manfaat yang dalam praktiknya hampir tidak dibutuhkan oleh siapa pun. Anda juga harus mempertimbangkan bahwa Auth0 memiliki kepentingan pribadi di sini, yang _tidak_ menguntungkan Anda sebagai pengembang: _"Layanan pihak ketiga seperti Auth0 dapat menangani penerbitan token dan kemudian server hanya perlu memverifikasi validitas token. "_ Mengalihdayakan otentikasi Anda adalah ide yang _mengerikan_, omong-omong.
• Cross Domain dan CORS: Lengkap dan omong kosong. Ini berbicara tentang _metode penyimpanan_, yang sepenuhnya terpisah dari apakah token _berisi_ data sesi atau tidak. Anda dapat memiliki ID sesi yang dikirim secara manual, atau Anda dapat menyimpan JWT dalam cookie. Tidak ada hubungannya dengan sesi JWT vs. - yang juga menunjukkan bias/ketidaktahuan penulis artikel, karena membandingkan "cookie vs. token" _tidak masuk akal untuk memulai_. Itu juga sepenuhnya mengabaikan masalah keamanan ini .
• Simpan Data di JWT: Bukan fitur. Hal yang sama berlaku untuk sesi. Dan kue, omong-omong.
• Kinerja: Ini hanya pengulangan dari poin "tanpa kewarganegaraan", sebagian besar - selain dari fakta bahwa tidak _sama sekali_ jelas apakah verifikasi kriptografis dapat mengalahkan sesuatu seperti Redis pada kinerja penanganan data sesi (perbandingan mereka dengan RDBMS tidak realistis) , ini juga merupakan pengoptimalan kinerja yang sama sekali tidak signifikan untuk hampir setiap aplikasi web. Ini disebut "optimasi prematur", dan secara luas direkomendasikan untuk alasan yang sangat bagus.
• Siap Seluler: Omong kosong. Jika pustaka HTTP Anda tidak mendukung cookie, _cari pustaka HTTP yang lebih baik_. Cookie didukung dengan baik, mereka hanya header HTTP.

Jadi tidak, artikel itu tidak membawa manfaat baru dari JWT yang belum saya bahas. Itu hanya salah mengartikan manfaat yang kadang-kadang (tanpa kewarganegaraan) sebagai sesuatu yang berlaku untuk setiap aplikasi (tidak), dan kemudian membuat perbandingan yang tidak masuk akal dan terlalu menekankan kinerja sesi untuk sisanya.

Saya pikir salah satu hal yang memicu reaksi keras terhadap repo ini tetapi reporter masalah adalah diskusi tentang fitur yang biasanya diharapkan dalam Sesi Cookie menggunakan JWT yang mengurangi beberapa manfaat inti JWT, terutama yang melibatkannya bisa tanpa kewarganegaraan.

Seperti yang telah saya katakan, ini hampir tidak pernah bermanfaat dalam praktik. Anda dapat terus mengulangi poin tanpa kewarganegaraan yang sama ini berulang-ulang, tetapi itu tidak akan membuatnya lebih valid atau berlaku. Ini _sama sekali bukan_ persyaratan tujuan umum.

Saya menganggap OK untuk memiliki JWT yang memberikan akses ke sumber daya dan sumber daya memiliki status untuk pengguna yang menolak akses ke layanan; dalam hal ini bukan JWT yang harus kadaluarsa, tetapi status pengguna yang mengakses layanan menggunakan JWT.

Dalam hal ini Anda sama sekali tidak memiliki manfaat dari semacam ID sesi reguler.

[...] Ketika saya menyebutkan CORS sebelumnya mungkin lebih baik untuk secara eksplisit menunjukkan kesulitan menggunakan beberapa domain dengan cookie. Tentu, Anda dapat mengatur domain wildcard, tetapi jika mereka cukup berbeda maka cookie sesi tradisional dengan cepat menjadi berat.

Ini, juga, sepenuhnya ortogonal pada intinya. Ini murni tentang di mana Anda _menyimpan_ pengidentifikasi Anda, bukan tentang apakah mereka _mengandung_ data sesi itu sendiri. Dan lagi, risiko keamanan .

tetapi penggunaan JWT hanya akan menjadi lebih menonjol sebagai titik awal untuk sesi yang diautentikasi

Dan itu sangat mengkhawatirkan saya, karena penggunaan yang menonjol itu didasarkan pada ketidaktahuan dan hype, dan disertai dengan banyak masalah keamanan. Ini adalah langkah mundur yang besar.

jadi untuk mengabaikan ini karena kami telah menggunakan cookie sesi untuk waktu yang lama

Saya tidak pernah mengatakan hal semacam itu. Saya telah memberikan beberapa _sangat_ alasan yang jelas mengapa JWT _secara objektif lebih rendah_ untuk manajemen sesi.

dan hanya mempelajari dan menggunakan JWT ketika mereka menemukan bahwa mereka tidak dapat membagikan cookie di seluruh domain

Dalam hal ini, masalah keamanan . Cookie _bukan opsional_.

atau perlu mengakses API pihak ketiga

Tidak relevan dengan sesi.

atau harus dapat menentukan kedaluwarsa tanpa memeriksa server

Tidak mungkin, karena server perlu mempertahankan kemampuan untuk membatalkan sesi secara eksplisit - mis. ketika pengguna mengubah kata sandi mereka atau menutup sesi lain secara paksa.

atau mempertanyakan penyimpanan kredensial login pengguna di perangkat seluler, dll. dll.

Kue. Selesai.

Mengecilkan keuntungan dari token stateless sebagai sesuatu yang tidak relevan kecuali Anda menjalankan situs perdagangan tingkat atas adalah tidak benar. Bahkan ketika kami menyelesaikan masalah dengan memperkenalkan lapisan status baru, pemisahan sesi dari server memiliki banyak keuntungan.

Namun Anda tidak menyebutkan satu pun dari mereka yang belum saya bahas, dan diperhitungkan dalam kesimpulan saya. Maaf, tetapi Anda membela pendekatan baru demi menjadi pendekatan baru, dan sepenuhnya mengabaikan _objektif, sifat teknis_ dari pendekatan yang berbeda.

Itulah yang disebut "hype", dan itu sangat berbahaya.

Stateless: penting saat aplikasi perlu berfungsi secara offline dan mempertahankan semacam makna.

Aplikasi offline tidak perlu autentikasi, _sama sekali_. Ada, menurut definisi, tidak ada interaksi dengan sistem lain.

Otentikasi Kredensial Lintas Domain: Penting jika Anda membagi aplikasi menjadi layanan mikro menggunakan beberapa server

Benar. Tetapi dalam kasus ini, Anda tidak menggunakan JWT _sebagai mekanisme sesi Anda_, Anda menggunakannya sebagai token sekali pakai yang dapat _dipertukarkan_ untuk satu sesi. Ada perbedaan yang sangat besar antara keduanya, dan pengorbanan yang dihadirkannya.

( EDIT: Tentu saja ini mengasumsikan _stateful_ microservices, dan dengan 'stateful' saya _not_ merujuk ke sesi, tetapi ke layanan itu sendiri. Untuk layanan mikro yang melakukan tugas stateless, token sekali pakai _tanpa_ menggunakan sesi sama sekali sudah cukup, dengan token sekali pakai yang dikeluarkan oleh server aplikasi. Untuk server aplikasi yang berbicara dengan layanan mikro, JWT juga baik-baik saja - tidak ada konsep "sesi" di sini, dan pencabutan token dapat dilakukan dengan mengubah kunci penandatanganan.)

Anda dapat terus menyangkal kegunaan JWT

Sekali lagi, saya tidak melakukan hal seperti itu. Ini sepenuhnya kata-kata Anda.

Ketika saya mencoba memberikan lebih detail Anda hanya mengabaikan kasus saya sebagai praktik yang tidak relevan atau buruk .. menurut saya salah begitu.

Kemudian saya mengharapkan Anda untuk menguraikan _mengapa_ itu salah, bukan hanya mengatakan "itu salah!" dan mengharapkan saya untuk menerimanya begitu saja. Saya secara konkret membahas setiap poin yang Anda berikan untuk alasan ini.

Mengandalkan cookie untuk mengelola sesi login iOS bukanlah solusi terbaik secara default.

Mengapa?

cookie dapat disalahgunakan

Itu pernyataan kosong. Disalahgunakan _bagaimana_? Dan bagaimana ini tidak berlaku untuk nilai yang disimpan di Penyimpanan Lokal? Dan apa hubungannya ini dengan JWT _at all_ mengingat bahwa "cookies" adalah metode penyimpanan, bukan mekanisme sesi? Membandingkan "JWT vs cookie" adalah membandingkan apel dan jeruk, mereka bahkan bukan kelas yang sama!

Penggunaan JWT untuk manajemen sesi berbeda dan memiliki sifat yang berbeda dari sesi cookie - ini tidak membuatnya lebih rendah tetapi hanya memiliki kriteria parameter operasi yang berbeda dalam merancang solusi yang tepat. Jika Anda ingin menggunakan cookie, gunakan cookie - jika memenuhi persyaratan Anda, gunakan cookie - mengapa Anda ingin mencegah orang lain mempertimbangkan pendekatan lain?

aku tidak. Saya telah _sangat jelas_ menunjukkan pengecualian di mana JWT _adalah_ solusi yang tepat. Saya juga _sangat jelas_ menunjukkan bahwa JWT tidak cocok sebagai mekanisme sesi tujuan umum . Berhentilah menaruh kata-kata di mulutku.

Anda menganggap sesi login sebagai nilai hanya untuk mengautentikasi terhadap server web Anda dengan penyimpanan persisten mengabaikan fakta bahwa saya mungkin ingin memiliki beberapa layanan data yang disediakan oleh penyedia alternatif yang memvalidasi JWT yang sama dan tidak memerlukan cookie baru untuk dibuat . Dalam hal apa ini tidak relevan dengan sesi???

Karena tidak ada alasan Anda tidak dapat menggunakan _both_ JWT dan sesi, untuk tujuan yang berbeda. Mencoba menyatukan semuanya menjadi satu mekanisme demi itu, adalah _sepenuhnya_ salah arah. Gunakan alat yang sesuai - "tidak memerlukan cookie baru untuk dibuat" adalah metrik yang sepenuhnya sewenang-wenang dan secara realistis, bukan manfaat yang Anda maksudkan.

Jika Anda melihat masalah keamanan, maka identifikasi dan tandai - mereka mungkin bukan penghenti acara tetapi mungkin berguna untuk diperhatikan dalam membuat keputusan. Kata-kata pedas Anda tidak mengakui ini atau bahkan menganggap ini sebagai kemungkinan karena Anda terus menyatakan bahwa cookie sesi harus digunakan untuk setiap aplikasi http yang hanya konyol.

Lagi. Bukan. Saya bilang. Berhenti memasukkan kata-kata ke dalam mulutku.

Contoh yang Anda kutip tentang peran sesi untuk menegakkan aturan tertentu seperti penghentian perubahan kata sandi atau untuk mengelola pembatasan layanan bukanlah fungsi built-in cookie sesi, hanya fungsi yang biasanya digunakan oleh pendekatan ini.

Ini adalah fitur yang _memerlukan_ sesi stateful, secara arsitektur. Saya tidak berpendapat bahwa ini disediakan oleh cookie sesi - saya berpendapat bahwa ini _tidak mungkin_ dengan token tanpa kewarganegaraan.

Jika solusi Anda cukup nyaman untuk menyediakan akses yang diautentikasi tanpa memeriksa db untuk mengakses sumber daya selama masa pakai sesi, lalu mengapa Anda bersikeras bahwa ini adalah kegagalan pendekatan ini.

Sekali lagi, bukan apa yang saya katakan.

Ketika kami menyarankan bahwa kontrol khusus ( jika mereka memerlukan semacam sesi yang dapat dihentikan ) dapat diperkenalkan sesuai kebutuhan, Anda menanggapi bahwa cookie memiliki ini di dalamnya sehingga Anda tidak boleh mencoba untuk melihat pendekatan lain. Menerapkan kontrol semacam ini bukanlah overhead yang signifikan untuk menghalangi sesi autentikasi JWT melalui cookie.

Intinya bukan di atas kepala. Intinya adalah menggunakan solusi yang dicoba dan diuji yang diketahui bekerja dengan baik . Menerapkan kembali keamanan Anda sendiri adalah ide yang buruk dalam situasi _any_, dan itu termasuk yang ini.

Anda mengabaikan jumlah permintaan cookie dan menyarankan bahwa satu-satunya pertimbangan kinerja adalah pencarian. Kebutuhan untuk mengoordinasikan penyegaran dll dan bergantung pada .. oh tidak apa-apa ... (menyerah di sini)

Apa yang kamu bicarakan? Cookie "menyegarkan" ditangani sebaris dalam respons HTTP dengan mengirimkan cookie baru - tidak ada tambahan yang terlibat di sini selain memperbarui penyimpanan sesi, yang telah saya bahas dalam contoh Redis saya. Jika menurut Anda ada pertimbangan kinerja lain, maka _daftarkan_.

Anda mungkin menyukai cookie yang dibatasi untuk domain dan menganggap bahwa mengizinkannya untuk digunakan lintas domain menimbulkan masalah keamanan yang menghalangi penggunaannya - tidak apa-apa - saya tidak.

Sekali lagi, bukan apa yang saya katakan.

JWT bukan hal berikutnya yang menggantikan semua cookie sesi tetapi juga tidak seserius kekejian (ketika digunakan untuk mengelola sesi) seperti yang Anda tunjukkan.

Iya itu mereka. Satu-satunya alasan Anda ingin menggunakan JWT untuk sesi adalah karena alternatifnya lebih buruk atau tidak mungkin, dan itu adalah _extremely_ edge case yang langka.

Anda memperlakukan keamanan sebagai sesuatu yang mutlak tanpa menyebutkan berbagai penyempurnaan yang dapat dilakukan pada pendekatan ini jika/bila diperlukan dan bagaimana kompleksitas evolusi tersebut dibandingkan dengan pendekatan berbasis sesi tradisional.

Saya hanya memperlakukan keamanan sebagai sesuatu yang mutlak ketika itu _adalah_ mutlak. Saya juga telah membahas kemungkinan cara untuk menyelesaikannya, _and_ menjelaskan bagaimana itu bukan solusi yang baik dibandingkan dengan sesi karena hasil bersihnya masih lebih buruk. Jika menurut Anda ada kasus atau solusi yang saya lewatkan, sebutkan. Berhentilah secara samar-samar menyinggung "pilihan lain" tanpa pernah benar-benar menjelaskan apa itu. Saat ini, sejauh yang saya tahu, Anda menggertak.

Tidak hype - tidak didasarkan pada ketidaktahuan tetapi merupakan solusi yang valid untuk masalah yang sering dihadapi saat membangun aplikasi hybrid yang memerlukan otentikasi silang untuk layanan yang tidak bertujuan untuk memberikan keamanan paling ketat yang dapat ditawarkan oleh teknologi dan untuk alasan yang baik - sangat praktis - sangat luas diadopsi - tidak membuat semuanya berubah menjadi omong kosong.

Mengulangi pernyataan Anda tidak membuatnya lebih benar. Saya sudah membahas mengapa ini salah, dan mengorbankan keamanan karena alasan hype tidak dapat diterima.

Bagi sebagian dari kita yang memiliki fleksibilitas untuk mengontrol sesi dengan perincian yang lebih baik daripada yang disediakan oleh cookie memberikan fleksibilitas yang lebih besar - jika Anda tidak melihat kasus penggunaan maka baiklah - saya berharap bahwa jika Anda membangun banyak aplikasi hibrida, Anda akan melakukannya dan mungkin kemudian Anda akan dapat mengartikulasikan kontraargumen dengan lebih baik untuk beberapa poin yang Anda sampaikan daripada saya.

Tidak ada _is_ "fleksibilitas yang lebih besar". Sekali lagi, jika menurut Anda ada, jelaskan caranya.

Bagaimanapun - Anda jauh lebih fasih daripada saya dan jelas tidak tergoyahkan dalam posisi Anda

Tidak. Saya hanya mengharapkan seseorang untuk memberikan argumen yang solid, berargumen dengan baik, dan benar secara teknis, jika mereka ingin mengubah pandangan saya. Anda belum melakukannya.

Saya ingat terakhir kali saya memiliki keterikatan yang tak henti-hentinya pada suatu pendekatan adalah ketika seseorang berargumen bahwa intisari auth tidak boleh diganti dengan cookie sesi.

... dan itu akan menjadi contoh sempurna dari kekeliruan semacam itu.

Intinya adalah bahwa setengah pernyataan Anda memasukkan kata-kata ke dalam mulut saya yang tidak pernah saya ucapkan, atau tersirat, atau maksudkan. Setengah lainnya berargumen untuk kompromi yang tidak perlu dalam keamanan, atau membuat klaim bergelombang tentang ada "manfaat lain" atau "solusi lain" tanpa pernah membahasnya lebih jauh.

Terus terang, saya bosan dengan ini - saya tidak berpikir diskusi ini akan mengarah ke arah yang konstruktif, dan itu mengacaukan utas. Satu-satunya alasan saya terus merespons, adalah karena risiko orang salah informasi oleh non-argumen Anda.

Jika Anda ingin tetap percaya bahwa JWT adalah cawan suci meskipun tidak memiliki argumen teknis untuk mendukung gagasan itu, maka itu adalah pilihan Anda - tetapi Anda _tidak akan meyakinkan saya_ kecuali Anda datang dengan _argumen teknis aktual_, dan terus mengulangi pernyataan yang sama di atas dan lagi tidak akan membantu siapa pun.

Untuk meringkas poin saya untuk mereka yang membaca sekilas seluruh diskusi:

• JWT tidak dirancang untuk sesi, tetapi untuk mentransfer klaim yang ditandatangani, biasanya sekali pakai.
• JWT tidak cocok untuk sesi, karena ketidakmampuan untuk membatalkan token, masalah dengan data basi, dan kebutuhan untuk menulis implementasi yang belum diuji untuk membuatnya berfungsi. Ini adalah masalah keamanan.
• "Cookies vs. JWT" bukan perbandingan yang valid; satu adalah mekanisme penyimpanan sementara yang lain adalah format token. Cookie tidak opsional , _terlepas_ dari apakah Anda menggunakan JWT atau tidak. Menyimpan segala jenis token di luar cookie adalah masalah keamanan.
• Terkadang Anda _tidak_ menggunakan sesi stateful karena Anda beroperasi pada skala yang sangat besar, dan dalam kasus tersebut JWT _can_ menjadi opsi 'paling buruk' yang tersedia - tetapi kasus ini jarang terjadi, dan kecuali jika Anda bekerja untuk situs besar berukuran Reddit, Anda mungkin tidak akan pernah bertemu dengan mereka.

(Omong-omong, Reddit menggunakan sesi stateful.)

Saya percaya bahwa maksud dari repo ini adalah untuk membuka jalan bagi implementasi SPA hybrid seluler dan penggunaan JWT sebagai pengganti sesi cookie adalah pendekatan yang umum dan hampir standar.
Salah satu pendorong untuk ini adalah masalah bahwa cookie terikat ke domain ketika SPA mungkin sebenarnya memerlukan akses ke layanan mikro di beberapa domain pada platform yang berbeda. JWT adalah pendekatan yang rapi untuk batasan cookie dalam konteks ini. Menggunakan pendekatan OAUTH atau OAUTH2 akan lebih kuat dari sudut pandang keamanan tetapi memperkenalkan kompleksitas yang mungkin tidak diperlukan untuk banyak aplikasi. Sesi pembawa JWT yang tidak bergantung pada negosiasi token AUTH bukanlah penyalahgunaan JWT tetapi aplikasi pendekatan yang kurang aman untuk mendapatkan kesederhanaan dan untuk aplikasi yang memiliki lebih banyak keuntungan dari implementasi cepat daripada keamanan tambahan yang disediakan oleh lebih banyak pendekatan yang kuat. Pada saat yang sama dengan merampingkan implementasi cepat, ini menyediakan jalur migrasi yang lebih jelas ke token sekali pakai daripada pendekatan lainnya.
Beberapa reaksi balik dan vitriol terhadap penggunaan header token JWT Bearer sebagai pengganti cookie sesi memang didasarkan pada beberapa orang yang menyajikannya sebagai evolusi atau peningkatan cookie secara lebih luas yang saya setujui tidak demikian. Saya meminta Anda untuk mempertimbangkan kasus penggunaan saya dan bagaimana Anda akan mendekatinya menggunakan cookie.
menggunakan JWT untuk manajemen sesi auth harus dilakukan dengan hati-hati dan kekurangannya harus dibuat eksplisit namun mengabaikannya sebagai hype yang tidak berguna yang selalu digunakan di luar konteks menyesatkan dan tidak benar.
Menggunakan JWT berarti Anda tidak perlu me-refresh cookie setiap kali klien menghubungi server. Keyakinan yang masuk akal dapat dijamin tanpa memeriksa basis data meskipun memperpanjang pemeriksaan ini semudah menggunakan cookie sesi.
Menggunakan JWT berarti bahwa klien dengan cookie yang diblokir tidak akan dipaksa untuk kembali menggunakan variabel pos tersembunyi, dll. sebagai pengisian ulang.
Menggunakan JWT di beberapa layanan memungkinkan layanan yang tidak memerlukan auth tetapi menginginkan beberapa indikasi validitas bidang data sederhana seperti uid yang dapat dibungkus menjadi JWT dan diteruskan.
Pendekatan JWT cocok untuk pendekatan OAUTH yang lebih canggih.
Permintaan JWT REST dapat dibuat tanpa memposting kredensial atau memerlukan permintaan cookie sebelum mengakses layanan yang dapat menyederhanakan implementasi REST/SPA.
Menggunakan header pembawa atau header cookie tidak jauh berbeda dalam hal keamanan (kecuali untuk pembatasan domain yang mungkin secara sah tidak diinginkan. (NB Saya tidak memasukkan kata-kata ke mulut Anda tetapi mencoba menafsirkan apa yang Anda singgung dengan mengatakan itu keamanannya lebih buruk)
Di mana periode ketidakhadiran yang lama umum/diharapkan seperti dengan aplikasi seluler, cookie mungkin kurang diinginkan daripada pendekatan JWT. Memiliki jalur yang lebih jelas untuk pemeriksaan kredensial mandiri dapat memfasilitasi perilaku tanpa memeriksa dengan server.
Jika Anda menerima bahwa ada kasus penggunaan untuk sesi yang mungkin memiliki periode offline yang berkepanjangan, maka sesi belum tentu stateful.
Jika Anda dapat menerima bahwa sesi dapat berhasil ada dengan beberapa status dari perspektif klien dan server, maka mungkin Anda dapat lebih dekat dengan kasus penggunaan yang mencakup periode non-konektivitas yang berkepanjangan dengan server (misalnya mengumpulkan data pengguna untuk pembaruan batch di sambungkan kembali). Ada kasus di mana klien dapat beroperasi lebih efektif mengetahui bahwa sesi telah kedaluwarsa dan penyegaran diperlukan tanpa mengelola lapisan data lain. Juga dapat menggunakan JWT sebagai validasi sesi bahkan setelah kata sandi diubah dll dapat berguna dalam beberapa kasus untuk memungkinkan data diteruskan ke lapisan logika bisnis dan memutuskan bagaimana menerima permintaan.
Anda terus memberi tahu saya bahwa cookie aman yang saya anggap mengacu pada implementasi di browser dll - di luar browser saya gagal melihat mengapa mereka secara inheren lebih aman - mungkin Anda bisa menguraikannya?
Di aplikasi SPA/Hybrid, ketergantungan pada cookie belum tentu satu-satunya posisi awal - mengandalkan penanganan cookie oleh browser tidak membawa Anda lebih dekat ke yang asli tetapi memperkenalkan ketergantungan pada UIWebView atau apa pun dan saya tidak tetap yakin bahwa itu akan selalu berperilaku seperti yang saya harapkan.
Token dapat disimpan dalam memori selama masa eksekusi aplikasi tanpa harus dipertahankan - ini tidak benar-benar sama dengan mengandalkan integritas cookie - ada kontrol yang lebih terperinci di iOS setidaknya pada izin penyimpanan yang ada di luar browser dan ini menurut saya lebih tepat daripada terikat pada pendekatan penyimpanan browser.
Cookie memang opsional - tidak ada undang-undang yang menyatakan bahwa Anda hanya boleh menggunakan cookie.
Pemisahan sesi dari server mungkin dalam beberapa kasus menjadi hal yang buruk tetapi tidak selalu - pendekatan modern termasuk penggunaan JWT memperkenalkan masalah baru tetapi juga fleksibilitas baru dan fleksibilitas ini tidak hanya mencakup pendekatan yang paling tidak buruk.

Untuk meringkas posisi saya:
Penggunaan JWT sebagai bagian dari solusi sesi autentikasi tidak selalu dikalahkan oleh cookie sesi
JWT cocok untuk sesi jika Anda mengetahui manfaatnya dan memiliki alasan untuk tidak memerlukan pembatalan sederhana.
Cookie bukan satu-satunya solusi.
Skala besar bukan satu-satunya kasus penggunaan untuk sesi stateless - menggunakan header JWT untuk mengautentikasi di seluruh domain/layanan adalah alasan yang sah untuk menggunakannya sebagai alternatif cookie sesi.

Saya meminta Anda untuk mempertimbangkan kasus penggunaan saya dan bagaimana Anda akan mendekatinya menggunakan cookie.

Tentu.

Menggunakan JWT berarti Anda tidak perlu me-refresh cookie setiap kali klien menghubungi server.

Ini sama untuk cookie sesi, cookie yang mengandung JWT, _dan_ token JWT itu sendiri - Anda hanya perlu secara eksplisit 'menyegarkan' mereka jika akan kedaluwarsa. Tidak ada perbedaan di sini.

Menggunakan JWT berarti bahwa klien dengan cookie yang diblokir tidak akan dipaksa untuk kembali menggunakan variabel pos tersembunyi, dll. sebagai pengisian ulang.

Pengguna yang memblokir cookie hampir pasti juga akan memblokir Penyimpanan Lokal dan tindakan persistensi lainnya (untuk alasan yang sama persis dengan mereka memblokir cookie). Ekstensi privasi melakukan hal yang sama. Sekali lagi, "JWT vs. cookie" _bukan perbandingan yang valid_, dan jika pengguna memblokir cookie, maka Anda tidak akan dapat mempertahankan token _anyway_. JWT atau tidak, tidak masalah.

(Jika pengguna memblokir cookie secara grosir, mereka sudah memilih untuk tidak memiliki persistensi data, jadi mencoba mendukung otentikasi untuk pengguna yang memblokir cookie adalah sedikit kerugian. Itulah tradeoff yang menyertainya, dan itu sepenuhnya masuk akal secara teknis. pertukaran.)

Menggunakan JWT di beberapa layanan memungkinkan layanan yang tidak memerlukan auth tetapi menginginkan beberapa indikasi validitas bidang data sederhana seperti uid yang dapat dibungkus menjadi JWT dan diteruskan.

Lihat suntingan posting saya sebelumnya (paragraf ketiga), yang membahas token sekali pakai dalam arsitektur terdistribusi. Ini bukan sesi dan seharusnya tidak persisten, jadi masalah yang saya jelaskan tidak berlaku di sana.

Pendekatan JWT cocok untuk pendekatan OAUTH yang lebih canggih.

OAuth menggunakan token sekali pakai. Ini bukan pengganti sesi. Sekali lagi, lihat editan posting saya sebelumnya.

Permintaan JWT REST dapat dibuat tanpa memposting kredensial atau memerlukan permintaan cookie sebelum mengakses layanan yang dapat menyederhanakan implementasi REST/SPA.

Mereka tidak bisa. Anda masih perlu mendapatkan JWT _entah bagaimana_, yang berarti perlu dikeluarkan oleh server, yang berarti Anda perlu meminta server untuk itu. Apakah server mengembalikan cookie atau header atau nilai yang berbeda tidak masalah. Dan sekali lagi, "cookies vs. JWT" bukanlah perbandingan yang valid.

Menggunakan header pembawa atau header cookie tidak jauh berbeda dalam hal keamanan (kecuali untuk pembatasan domain yang mungkin secara sah tidak diinginkan.

Tidak melihat argumen di sini.

Di mana periode ketidakhadiran yang lama umum/diharapkan seperti dengan aplikasi seluler, cookie mungkin kurang diinginkan daripada pendekatan JWT. Memiliki jalur yang lebih jelas untuk pemeriksaan kredensial mandiri dapat memfasilitasi perilaku tanpa memeriksa dengan server.

Ini tidak menguntungkan - Anda tidak _membutuhkan_ token sampai Anda tetap ingin berkomunikasi dengan server, jadi Anda bisa mencoba mengajukan permintaan dan menangani 403 saat itu terjadi. Mencoba menghindari meminta server untuk sesuatu yang secara inheren melibatkan berbicara dengan server (yaitu, membuat permintaan yang diautentikasi) tidak masuk akal.

Belum lagi, jika Anda ingin tahu sebelumnya apakah sesi Anda akan kedaluwarsa, Anda bisa mengirim cookie terpisah untuk ini. Karena ini hanya petunjuk UX untuk aplikasi, Anda bahkan tidak perlu memverifikasi keasliannya - dan Anda perlu menangani kegagalan autentikasi yang tidak terduga _anyway_ karena kemiringan jam dan perubahan kunci penandatanganan.

Di aplikasi SPA/Hybrid, ketergantungan pada cookie belum tentu satu-satunya posisi awal - mengandalkan penanganan cookie oleh browser tidak membawa Anda lebih dekat ke yang asli tetapi memperkenalkan ketergantungan pada UIWebView atau apa pun dan saya tidak tetap yakin bahwa itu akan selalu berperilaku seperti yang saya harapkan.

Tidak. Pustaka HTTP apa pun yang masuk akal - browser atau bukan - akan mendukung cookie. Cookie _tidak berarti_ eksklusif untuk browser, mereka adalah fitur HTTP seperti yang lainnya.

Pemisahan sesi dari server mungkin dalam beberapa kasus menjadi hal yang buruk tetapi tidak selalu - pendekatan modern termasuk penggunaan JWT memperkenalkan masalah baru tetapi juga fleksibilitas baru dan fleksibilitas ini tidak hanya mencakup pendekatan yang paling tidak buruk.

Saya masih belum melihat contoh konkret dari 'fleksibilitas' seperti itu.

Penggunaan JWT sebagai bagian dari solusi sesi tidak selalu dikalahkan oleh cookie sesi

Itu pernyataan yang sangat ambigu. Anda membandingkan menggunakan JWT sebagai _bagian dari_ solusi, dengan menggunakan cookie sesi sebagai solusi _seluruh_. Ini tidak berlawanan - banyak arsitektur kompleks akan memerlukan kombinasi cookie sesi dan token JWT sekali pakai, misalnya untuk sistem SSO atau arsitektur terdistribusi.

JWT cocok untuk sesi jika Anda mengetahui manfaatnya dan memiliki alasan untuk tidak memerlukan pembatalan sederhana.

Tidak. Token JWT adalah _pilihan terakhir_ ketika Anda tidak dapat memenuhi persyaratan dengan cookie sesi.

Cookie bukan satu-satunya solusi.

Secara teknis benar.

Skala besar bukan satu-satunya kasus penggunaan untuk sesi stateless.

Ini _adalah_ satu-satunya usecase yang saya ketahui, dan saya belum melihat yang valid lainnya yang disebutkan di seluruh utas ini. Ingatlah bahwa saya berbicara secara khusus tentang _sessions_ stateless, bukan tentang token stateless _secara umum_.

Saya menanyakan ini kepada Anda - bagaimana cara menyebarkan aplikasi yang menggunakan 3 layanan berbeda (mungkin pada infrastruktur wadah yang berbeda, dll) dan mengintegrasikannya ke dalam aplikasi dengan mengandalkan cookie sesi? Jika saya menyiapkan layanan auth dan ingin memisahkannya dari layanan lain, apakah pendekatan terbaik untuk menjalankan penangan sesi cookie proxy bersama? Apakah ini kasus tepi?
Bagaimana cookie memberi saya keamanan, fleksibilitas, kepatuhan standar yang lebih besar daripada menggunakan JWT yang berjalan lama untuk melacak sesi saya. Dengan asumsi bahwa saya tidak ingin atau peduli untuk dapat mengakhiri sesi sesuai permintaan (walaupun itu bukan manfaat yang melekat pada cookie melainkan dalam penanganan permintaan), bahwa saya menggunakan header Bearer dengan setiap posting dan menanggapi kegagalan dengan Prompt/posting auth untuk mendapatkan sesi JWT untuk dimasukkan dalam semua header - saya mungkin bodoh tapi saya tidak melihat bagaimana ini kurang aman? Detail cookie tersedia di aplikasi hybrid seperti halnya token meskipun ada sedikit kontrol atas kegigihan ... Saya kira saya tidak mengerti mengapa ini adalah pendekatan yang buruk. Tentu Anda perlu memberikan kredensial untuk mendapatkan JWT tetapi Anda melakukannya sekali - bukan pada setiap layanan.

Saya menanyakan ini kepada Anda - bagaimana cara menyebarkan aplikasi yang menggunakan 3 layanan berbeda (mungkin pada infrastruktur wadah yang berbeda, dll) dan mengintegrasikannya ke dalam aplikasi dengan mengandalkan cookie sesi?

Tergantung pada apa yang dilakukan 3 layanan tersebut. Bisakah Anda menguraikan?

Jika saya menyiapkan layanan auth dan ingin memisahkannya dari layanan lain, apakah pendekatan terbaik untuk menjalankan penangan sesi cookie proxy bersama? Apakah ini kasus tepi?

Anda akan memiliki masalah layanan auth token JWT sekali pakai yang menunjukkan otentikasi yang berhasil, secara opsional termasuk 'informasi profil' untuk pengguna, tergantung pada arsitektur Anda. Kemudian, tergantung pada aplikasinya:

1. Jika situs web biasa: Layanan autentikasi dialihkan ke halaman autentikasi di server aplikasi, mis. meneruskan token JWT sebagai parameter kueri. Server aplikasi memvalidasi token, dan memberi pengguna cookie sesi.
2. Jika SPA: Layanan auth mengembalikan token yang dihasilkan dalam respons (JSON?). Aplikasi frontend membuat permintaan HTTP ke titik akhir otentikasi server aplikasi, termasuk token sebagai parameter, dan setelah validasi oleh server aplikasi, menerima cookie sesi sebagai gantinya.
3. Jika aplikasi mandiri (desktop atau seluler): Seperti untuk SPA, tetapi menggunakan pustaka HTTP yang mendukung cookie, bukan aplikasi frontend di browser.

Dalam kedua kasus, token JWT hanya akan valid selama sekitar 5 menit (untuk memperhitungkan kemiringan jam), dan digunakan sekali - untuk menukarnya dengan sesi di server aplikasi. Jika Anda menyertakan informasi profil dalam token, layanan autentikasi tetap sepenuhnya dipisahkan dari aplikasi.

EDIT: Menambahkan kasing aplikasi mandiri.

Mari kita asumsikan kita berada dalam skenario pengembangan aplikasi seluler SPA / Hybrid. Juga asumsikan bahwa kita hanya menggunakan JWT untuk sesi - bukan OUATH dengan token auth dan pembawa - cukup login dan terima token pembawa.
Mari kita bayangkan bahwa kita memiliki aplikasi waktu nyata dengan setiap sesi membuat permintaan ke semua 3 layanan setiap 5-15 detik. Banyak pengguna masuk untuk pemeriksaan status cepat atau untuk memposting data GIS atau sesuatu sehingga waktu penggunaan rata-rata kurang dari 1 menit tetapi ingin memulai aplikasi - tutup - mulai ulang 3 hari kemudian tanpa kredensial dll. (menambahkan detail yang sebagian besar tidak relevan di sini tetapi hal-hal yang akan menjauhkan saya dari cookie)

Sebagai contoh, katakanlah saya telah membuat layanan AWS dengan layanan kueri grafik, layanan pemetaan atau GIS pada ruang rak buruh pelabuhan dan antarmuka REST ke postgres db untuk mengelola data profil pengguna. Saya dapat menggunakan JWT yang sama dalam permintaan tajuk ke semua layanan REST dan memvalidasi terhadap rahasia umum untuk berbagi validasi dari JWT yang dikeluarkan satu kali.
Mari kita asumsikan bahwa mereka stateful dalam konteks mereka sendiri tetapi hanya longgar dalam konteks bersama.
Ini adalah spesifikasi masalah yang cocok dengan solusi yang saya usulkan menggunakan JWT sebagai token sesi sebagai Token Pembawa dan dengan lingkungan yang serupa, saya bertanya bagaimana Anda akan mendekati menggunakan cookie sesi sehingga kami dapat membandingkan.

Katakanlah mereka semua membutuhkan keyakinan yang masuk akal bahwa pengguna adalah siapa yang mereka katakan.
Solusi saya adalah membuat token JWT sebagai tanggapan atas pos kredensial yang digunakan di semua layanan dalam header HTTP untuk mengautentikasi - dengan validasi dilakukan dengan rahasia JWT bersama di semua layanan.
Layanan auth menghasilkan token dan mengembalikannya saat login. Token disertakan dalam permintaan header ke semua layanan lain di domain yang berbeda. Jika menggunakan cookie, kami perlu membuat cookie baru untuk setiap domain. Mengapa saya ingin layanan membuat permintaan baru untuk memvalidasi atau mendapatkan cookie untuk setiap http yang diterima ketika saya dapat dengan yakin bergantung pada JWT? Jika saya memiliki 5 layanan, saya sekarang perlu mengelola 5 cookie sesi yang berbeda dan memastikan koordinasi di antara semua ini. Dalam banyak kasus, ini bisa menjadi pendekatan yang tepat, tetapi dalam banyak kasus ini menurut saya terlalu rumit untuk sesuatu yang cepat dan sederhana untuk diterapkan dan tidak mengekspos lubang keamanan serius yang dapat saya lihat dengan jelas.
Mengapa membatasi jangka waktu JWT? Cookie secara tradisional berumur pendek karena mereka menganggap kontak server biasa - bagaimana jika saya tidak ingin kedaluwarsa dengan cepat tetapi saya senang memiliki sesi basi yang berjalan lama karena saya memutuskan bahwa trade-off dari otentikasi ulang adalah risiko yang lebih besar.

Jika saya memahami dengan benar dalam situasi Anda, saya mendapat 9 permintaan yang terpental setiap periode, bukan 3. Saya memiliki server auth yang di-wack untuk mengonfirmasi sesi yang ditetapkan. Saya punya lebih banyak kode dan lebih banyak bagian yang bergerak. Saya mendapatkan keuntungan karena dapat mengakhiri sesi setiap periode tetapi bagaimana jika itu bukan keharusan. Bagaimana jika saya tidak peduli tentang menerima data yang diposting selama 48 jam setelah pengguna dihentikan dan menggunakan server auth untuk permintaan baru, saya masih dapat memfilter apa yang tidak saya butuhkan?

Dalam kasus penggunaan ini, kemiringan waktu kecil tidak relevan karena perincian sesi diatur dengan tepat dan seperti halnya cookie sesi, saya akan menerapkan klien menyegarkan JWT melalui server auth dalam periode waktu tunggu yang sesuai. Sejauh 'profil' berjalan, mari kita tetap menggunakan share uid sebagai id umum (jika saya mengerti dengan benar) dan implementasi sisi server berisi rahasia bersama untuk menandatangani/memvalidasi JWT.

Dalam arsitektur yang saya usulkan, saya tidak perlu mencabut token dengan perincian yang lebih baik daripada yang disediakan oleh batas waktu JWT, jadi mengapa saya harus menggunakan cookie sesi?
Dalam arsitektur yang saya usulkan, Anda dapat membuat dependensi antara status layanan tetapi Anda dapat merancang ini daripada bergantung padanya yang terpusat dan perlu menjembatani semuanya kembali ke auth secara default. Kuncinya adalah fleksibilitas - dan itu datang dengan biaya mewujudkan dependensi tetapi ini ada di wajah Anda sejak awal dan bukan lapisan di atas sesuatu yang meskipun diimplementasikan pada semua platform ditangani secara berbeda di seluruh kerangka kerja. Mungkin tidak sepele untuk memperbarui cookie kedaluwarsa untuk sesi dengan node, php dan penanganan default sesi cookie eksotis tanpa benar-benar sehingga Anda mungkin didorong untuk hanya memposting permintaan server auth secara langsung sehingga kami tidak hanya menembakkan 3 x permintaan tetapi ada 3x permintaan untuk klien.

Jika saya menyelaraskan dengan arsitektur yang Anda usulkan, maka saya memang perlu bergulat dengan batas waktu di beberapa cookie. Sebagai contoh jika klien masuk dan menerima cookie sesi yang diautentikasi yang kedaluwarsa dalam 1 jam
dan kemudian 40 menit kemudian mereka memposting nilai cookie sesi ini ke layanan pertama kami yang kemudian menanyakan server auth sebelum mengeluarkan cookie domain lokal, apakah kami meretas cookie auth asli internal yang kedaluwarsa atau apakah kami menetapkan batas waktu pada cookie layanan menjadi 20 menit dan ketika ini kedaluwarsa memicu penyegaran cookie auth. Kecuali saya kehilangan solusi yang jelas, ini dapat dengan mudah berubah menjadi tumpukan besar spagetti yang dapat sepenuhnya dihindari dengan menggunakan satu JWT dengan satu ttl yang dapat disegarkan melalui salah satu layanan (memahami bagaimana ini mungkin memperluas token life ) atau dengan meminta penyegaran melalui server auth.

Saya dapat membahas pendekatan terhadap data basi tetapi ruang lingkup masalah dalam kasus penggunaan ini tidak bergantung pada pembatalan kredensial basi (dari perspektif server auth) jadi ini tidak akan relevan.

Pemahaman saya adalah bahwa kami sedang mendiskusikan pernyataan Anda bahwa menggunakan JWT sebagai pendekatan manajemen sesi yang diautentikasi secara inheren lebih rendah dan tidak benar dibandingkan penggunaan cookie sesi sebagai pendekatan manajemen sesi yang diautentikasi untuk layanan lintas domain dalam aplikasi seluler hybrid yang akan dijalankan pada perangkat sebentar-sebentar tanpa memasok kredensial.

Saya mencoba memastikan apakah Anda akan berpendapat bahwa pendekatan yang diusulkan secara inheren kurang aman atau kurang 'benar' dengan cara apa pun. Seperti yang saya lihat, ada keuntungan yang signifikan dalam kesederhanaan arsitektur ini dan tidak ada keuntungan yang ditawarkan oleh solusi yang lebih berat dan lebih kompleks yang diperlukan untuk mengelola sesi di semua layanan yang belum diperhitungkan dan ditukar dengan arsitektur yang lebih sederhana. Jika Anda dapat menunjukkan bagaimana solusi ini akan mengalami masalah yang tidak dialami menggunakan cookie untuk mengelola sesi, maka itu akan sangat membantu saya untuk memahaminya secara eksplisit (yaitu bagaimana keamanan dikompromikan)

Layanan hampir tidak masalah - tidak yakin apa yang Anda singgung?

Ada perbedaan antara layanan stateful dan stateless.

Katakanlah [...]

Ini menjelaskan bagaimana Anda akan memecahkan masalah, bukan apa masalahnya _is_. Ini tidak berguna ketika meminta saya untuk menjelaskan cara mendekatinya dengan sesi, karena itu sudah mengasumsikan bahwa Anda _tidak_ akan menggunakan sesi. Jelaskan masalahnya sebagai gantinya.

kapan saya bisa percaya diri bergantung pada JWT?

Anda tidak bisa.

Jika saya memiliki 5 layanan, saya sekarang perlu mengelola 5 cookie sesi yang berbeda dan memastikan koordinasi di antara semua ini.

Tidak sepertinya. Lihat komentar saya tentang layanan stateful vs stateless.

Dalam banyak kasus, ini bisa menjadi pendekatan yang tepat, tetapi dalam banyak kasus ini menurut saya terlalu rumit untuk sesuatu yang cepat dan sederhana untuk diterapkan dan tidak mengekspos lubang keamanan serius yang dapat saya lihat dengan jelas.

Otentikasi dan manajemen sesi, terutama dalam arsitektur terdistribusi, _is_ kompleks. Ada alasan mengapa para insinyur menghindari arsitektur terdistribusi sedapat mungkin di masa lalu. "Cukup gunakan JWT" menutupi ini dan berpura-pura lebih mudah daripada yang sebenarnya, dengan sepenuhnya mengabaikan kedaluwarsa data dan pembatalan sesi.

Lubang keamanan ada di sana, dan saya telah melakukan beberapa upaya untuk menjelaskannya - bahwa Anda tidak dapat melihatnya dengan jelas bukanlah sesuatu yang dapat saya lakukan, jika Anda tidak mengajukan pertanyaan spesifik tentang bagian-bagian yang tidak jelas bagi Anda. .

Mengapa membatasi jangka waktu JWT?

Dalam contoh yang saya berikan? Karena mereka dimaksudkan sebagai token pertukaran sekali pakai, bukan pengidentifikasi persisten. Anda tidak ingin mereka menjadi pengenal tetap, karena Anda tidak dapat mencabutnya.

Cookie secara tradisional berumur pendek karena mereka menganggap kontak server biasa - bagaimana jika saya tidak ingin kedaluwarsa dengan cepat tetapi saya senang memiliki sesi basi yang berjalan lama karena saya memutuskan bahwa trade-off dari otentikasi ulang adalah risiko yang lebih besar.

Tidak ada risiko dalam menyegarkan sesi.

abaikan profil atau kemiringan jam - detail yang tidak berdampak besar pada diskusi kita dalam hipotetis ini karena masalah yang sama berlaku jika menggunakan cookie untuk skenario serupa.

Mereka sama pentingnya sebagai bagian dari sistem otentikasi yang kuat seperti semua poin lain yang disebutkan. Mengabaikan mereka bukanlah pilihan. Dan lagi, ini _not_ tentang "cookies", ini tentang sesi.

Untuk sesi, tidak, masalah yang sama _not_ berlaku; penyimpanan sesi terpusat/status berarti data tidak menjadi basi sama sekali dan informasi profil dapat diambil kapan saja, dan kemiringan jam adalah masalah untuk token validitas terbatas apa pun yang dipertukarkan di antara sistem yang berbeda.

Sepertinya kami dapat meringkas keberatan Anda terhadap JWT karena pendekatan manajemen sesi dapat memberikan Anda lampiran definisi sesi yang memerlukan pencabutan per permintaan (dan beberapa fitur lain yang secara tradisional menjadi bagian dari memastikan bahwa pengguna diotorisasi untuk mengakses) dan bahaya yang terkait dalam menyegarkan mereka (jika mereka dicegat) . Pemrosesan terdistribusi adalah norma baru - banyak layanan sangat umum - jika kita ingin mengadopsi penggunaan pendekatan semacam ini untuk arsitektur multi-layanan maka kita perlu sepenuhnya memahami konsekuensinya. Database terdistribusi telah ada sejak lama. Penyimpanan data terdistribusi seperti DNS sudah ada sejak awal. Terkadang kesederhanaan arsitektur memberikan lebih banyak manfaat daripada mencoba menekan standar dominan yang ada di luar batas desainnya. Jika kami mengetahui masalah ACID transaksional dalam sesi permintaan layanan kami, maka tidak ada alasan kami tidak menggunakan pendekatan manajemen sesi JWT untuk mengotentikasi layanan untuk sepenuhnya memanfaatkan kemungkinan tanpa dibatasi oleh apa yang dengan cepat menjadi infrastruktur yang kompleks jika kami bersikeras pada hard kendala dan mencoba cookie sesi sepatu-tanduk sebagai solusi yang lebih unggul.
@ joepie91 - jika perlu, Anda dapat menggunakan autentikasi utama dan meminta ini untuk menyegarkan JWT. Sekali lagi - penggunaan JWT untuk akses layanan sesi lintas domain dapat digunakan sebagai bagian dari solusi dan sesi cookie juga digunakan jika sesuai. Intinya adalah bahwa JWT sebagai bagian dari manajemen sesi - bahkan untuk mengakses subset layanan - saya tidak percaya pendekatan jahat yang tidak memiliki peran.
cookie sesi https juga memiliki risiko - mengejutkan berapa banyak situs yang tidak menyetel tanda ssl dan meneruskan cookie sebagai teks biasa saat berkomunikasi dengan SSL. Apakah ini membuat sesi cookie berbahaya?
Risiko terbesar yang tampaknya dapat saya temukan adalah bahwa pembuat kode mengizinkan token dikirim ke server yang salah dan token tersebut secara efektif memungkinkan pihak ketiga untuk mengakses sumber daya pengguna sekunder ini. Ini harus ditandai dengan huruf merah besar di suatu tempat dan menempatkan tanggung jawab yang kuat pada pengembang untuk memastikan bahwa ini tidak terjadi. Pengembang harus mengambil langkah-langkah yang tepat untuk memastikan bahwa langkah-langkah keamanan yang diperlukan telah diambil dan repo seperti ini harus menjelaskan beberapa pendekatan ini dan memasukkannya dalam contoh. Dalam pikiran saya, ini adalah harga yang dapat diterima untuk membayar fleksibilitas otentikasi layanan terbatas waktu lintas domain ke layanan non-kritis.
Dalam merancang solusi yang kompleks, kemungkinan akan menyertakan cookie sesi di akhir autentikasi dan dapat diperluas untuk menyertakan token sekali pakai dll jika sesuai. Intinya adalah hal ini mungkin dan sementara ada tempat yang bisa salah dan mengekspos risiko, ini memberikan kesempatan untuk membangun aplikasi yang lebih kaya dan lebih ramping dalam banyak kasus dan untuk alasan ini saya tidak percaya bahwa repo ini harus dibuang seperti yang disarankan oleh pencatat masalah.
Kecenderungan untuk mencoba mendapatkan yang terbaik dari kedua dunia dengan menggunakan JWT sebagai string sesi bagi saya tampaknya menimbulkan masalah - yang paling mencolok adalah periode timeout/TTL yang mungkin saling bertentangan. Itu juga memberlakukan pembatasan akses domain yang sama yang mungkin telah kami coba hindari sejak awal sehingga menempatkannya dalam contoh dasar mungkin membuat orang bertanya mengapa menggunakan JWT sejak awal?

Penggunaan JS sebagai ketergantungan cukup kecil - dalam konteks SPA seluler hibrida, sepertinya Anda tidak perlu mengakomodasi klien gratis JS. Menyarankan bahwa ini adalah masalah sementara juga mengklaim bahwa redis menyediakan opsi yang efisien untuk penyimpanan sesi tampaknya sedikit kontradiktif.
Kedaluwarsa dalam JWT tidak sia-sia karena menyediakan batas waktu sesi yang harus ditangani baik dengan menyegarkan ( persis seperti sesi cookie disegarkan ) atau memerlukan otentikasi ulang. Memiliki JWT yang ditandatangani memastikan bahwa itu tidak dirusak dan dengan demikian menghilangkan persyaratan mutlak untuk memvalidasi terhadap sisi server penyimpanan persisten meskipun ini dapat dilakukan jika diinginkan dan mencapai hasil yang sama seperti sesi cookie tanpa implementasi yang terlalu banyak pendapat dan dengan kemampuan untuk memanfaatkan lintas domain jika sesuai. Dalam aplikasi seluler hybrid, penyimpanan cookie atau JWT di penyimpanan lokal kembali memberikan kontrol lebih. Keberatan terhadap penggunaan penyimpanan lokal atas keamanan implementasi browser adalah masalah kepercayaan pada vendor dan penerimaan mereka atas penanganan kredensial ini.
Fleksibilitas ini berguna bagi banyak pengembang SPA hybrid seluler tetapi memerlukan pemahaman tentang batasannya.
JWT dapat dibatalkan hanya dengan mengubah kunci penandatanganan dan sekali lagi ini memberikan fleksibilitas - Anda dapat menggunakan kunci penandatanganan pribadi bersama yang umum di seluruh layanan atau menghasilkan secara acak per sesi pengguna dan menyadari manfaat penolakan cookie sesi.
Hampir semua kerangka kerja JS modern mendukung JWT dan akan sulit untuk menemukan platform utama yang tidak - beberapa namun sangat mungkin tidak (plugin Wordpress JWT .. hmm .. tidak melihat tetapi membuat saya gugup ).
Penggunaan JWT harus menyertakan latar belakang dalam OAUTH dan pengorbanan serta manfaat menggunakan sesi cookie. Bagi saya ada keuntungan kerja nyata bagi pengembang hibrida seluler rata-rata yang menggunakan banyak layanan tetapi ada jebakan yang mudah jatuh. Kita mungkin membutuhkan banyak contoh untuk menggambarkan sepenuhnya.

_Alasan asli_ saya untuk menggunakan JWT sebagai Token untuk otorisasi adalah bahwa memverifikasi JWT terikat dengan CPU (_laptop "lama" saya dapat memverifikasi 180k JWT per detik_) sebaliknya jika kita menggunakan token sederhana dan harus mencarinya dalam memori (atau Database) operasi akan menjadi I/O-terikat (_atau lebih buruk Jaringan-terikat_) yang akan _jauh lebih lambat_.
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

Sistem manajemen sesi kami _first_ memeriksa apakah JWT valid dengan memverifikasi bahwa itu _ditandatangani_ menggunakan kunci kami - dan menolak pesan _early_ jika tidak - dan _then_ memeriksa apakah sesi belum dibatalkan (misalnya oleh pengguna yang keluar) .

Saya tahu JWT mungkin tidak _dirancang_ untuk digunakan sebagai token di header Otorisasi, tetapi saya rasa saya tidak _sepenuhnya mengerti_ mengapa ini adalah "ide buruk" mengingat itu _lebih cepat_ daripada sistem manajemen sesi lainnya...

Catatan: Saya masih setuju bahwa sudut "tanpa cookie" bukanlah cara yang tepat untuk memulai readme/tutorial ini. 👍