Otentikasi Token vs. Cookies

Apa perbedaan antara otentikasi token dan otentikasi menggunakan cookie?

Saya mencoba menerapkan Demo Ember Auth Rails tetapi saya tidak memahami alasan di balik penggunaan otentikasi token seperti yang dijelaskan dalam FAQ Ember Auth pada pertanyaan "Mengapa otentikasi token?"

Aplikasi web pada umumnya sebagian besar tanpa kewarganegaraan , karena sifat permintaan / responsnya . Protokol HTTP adalah contoh terbaik dari protokol tanpa negara . Tetapi karena sebagian besar aplikasi web membutuhkan status , untuk menahan status antara server dan klien, cookie digunakan sedemikian rupa sehingga server dapat mengirim cookie dalam setiap respons kembali ke klien. Ini berarti permintaan berikutnya yang dibuat dari klien akan menyertakan cookie ini dan dengan demikian akan dikenali oleh server. Dengan cara ini server bisa mempertahankan sesi dengan stateless klien, mengetahui sebagian besar segala sesuatu tentang aplikasi negara , tetapi disimpan di server. Dalam skenario ini, klien tidak memegang saat ininegara , yang bukan cara kerja Ember.js .

Di Ember.js semuanya berbeda. Ember.js membuat pekerjaan programmer lebih mudah karena memegang memang negara untuk Anda, klien, mengetahui setiap saat tentang nya negara tanpa harus membuat permintaan ke server meminta negara data.

Namun, status penyimpanan di klien terkadang juga dapat menyebabkan masalah konkurensi yang tidak ada dalam situasi tanpa kewarganegaraan . Ember.js, bagaimanapun, menangani masalah ini juga untuk Anda; khususnya ember-data dibangun dengan pemikiran ini. Kesimpulannya, Ember.js adalah kerangka kerja yang dirancang untuk klien stateful .

Ember.js tidak berfungsi seperti aplikasi web stateless biasa di mana sesi , status, dan cookie terkait ditangani hampir sepenuhnya oleh server. Ember.js memegang nya negara sepenuhnya dalam Javascript (dalam memori klien, dan tidak dalam DOM seperti beberapa kerangka kerja lainnya) dan tidak perlu server untuk mengelola sesi. Hal ini menyebabkan Ember.js menjadi lebih serbaguna dalam banyak situasi, misalnya saat aplikasi Anda dalam mode offline.

Tentunya, untuk alasan keamanan, diperlukan semacam token atau kunci unik untuk dikirim ke server setiap kali permintaan dibuat untuk diautentikasi . Dengan cara ini server dapat mencari token pengiriman (yang awalnya dikeluarkan oleh server) dan memverifikasi apakah itu valid sebelum mengirim tanggapan kembali ke klien.

Menurut pendapat saya, alasan utama mengapa menggunakan token otentikasi daripada cookie seperti yang dinyatakan dalam FAQ Ember Auth terutama karena sifat kerangka kerja Ember.js dan juga karena lebih cocok dengan paradigma aplikasi web yang stateful . Oleh karena itu, mekanisme cookie bukanlah pendekatan terbaik saat membuat aplikasi Ember.js.

Saya berharap jawaban saya akan memberi makna lebih pada pertanyaan Anda.

HTTP bersifat stateless. Untuk memberi Anda otorisasi, Anda harus "menandatangani" setiap permintaan yang Anda kirim ke server.

Otentikasi token

• Permintaan ke server ditandatangani dengan "token" - biasanya itu berarti menyetel header http tertentu, namun, header tersebut dapat dikirim di bagian mana pun dari permintaan http (badan POST, dll.)

• Kelebihan:

  • Anda hanya dapat mengotorisasi permintaan yang ingin Anda otorisasi. (Cookie - bahkan cookie otorisasi dikirim untuk setiap permintaan.)
  • Kebal terhadap XSRF (Contoh singkat XSRF - Saya akan mengirimi Anda tautan di email yang tampilannya seperti itu <img src="http://bank.com?withdraw=1000&to=myself" />, dan jika Anda masuk melalui otentikasi cookie ke bank.com, dan bank.com tidak memiliki sarana XSRF apa pun perlindungan, saya akan menarik uang dari akun Anda hanya dengan fakta bahwa browser Anda akan memicu permintaan GET resmi ke url itu.) Perhatikan ada tindakan anti pemalsuan yang dapat Anda lakukan dengan otentikasi berbasis cookie - tetapi Anda harus menerapkannya.
  • Cookie terikat ke satu domain. Cookie yang dibuat di domain foo.com tidak dapat dibaca oleh domain bar.com, sementara Anda dapat mengirim token ke domain mana pun yang Anda suka. Ini sangat berguna terutama untuk aplikasi halaman tunggal yang menggunakan beberapa layanan yang memerlukan otorisasi - jadi saya dapat memiliki aplikasi web di domain myapp.com yang dapat membuat permintaan sisi klien resmi ke myservice1.com dan ke myservice2.com.
• Kekurangan:
  • Anda harus menyimpan token di suatu tempat; sementara cookie disimpan "di luar kotak". Lokasi yang terlintas dalam pikiran adalah localStorage (con: token tetap ada bahkan setelah Anda menutup jendela browser), sessionStorage (pro: token dibuang setelah Anda menutup jendela browser, kontra: membuka tautan di tab baru akan membuat tab itu anonim) dan cookie (Pro: token akan dibuang setelah Anda menutup jendela browser. Jika Anda menggunakan cookie sesi, Anda akan diautentikasi saat membuka tautan di tab baru, dan Anda kebal terhadap XSRF karena Anda mengabaikan cookie untuk otentikasi, Anda hanya menggunakannya sebagai penyimpanan token. Kontra: cookie dikirim untuk setiap permintaan tunggal. Jika cookie ini tidak ditandai sebagai https saja, Anda terbuka untuk serangan manusia di tengah.)
  • Sedikit lebih mudah untuk melakukan serangan XSS terhadap otentikasi berbasis token (yaitu jika saya dapat menjalankan skrip yang diinjeksi di situs Anda, saya dapat mencuri token Anda; namun, otentikasi berbasis cookie juga bukan peluru perak - sementara cookie ditandai sebagai http-only tidak dapat dibaca oleh klien, klien masih dapat membuat permintaan atas nama Anda yang secara otomatis akan menyertakan cookie otorisasi.)
  • Permintaan untuk mengunduh file, yang seharusnya hanya berfungsi untuk pengguna yang berwenang, mengharuskan Anda menggunakan API File. Permintaan yang sama bekerja di luar kotak untuk otentikasi berbasis cookie.

Otentikasi cookie

• Permintaan ke server selalu masuk dengan cookie otorisasi.
• Kelebihan:
  • Cookie dapat ditandai sebagai "hanya http" yang membuatnya tidak mungkin untuk dibaca di sisi klien. Ini lebih baik untuk perlindungan serangan XSS.
  • Keluar dari kotak - Anda tidak perlu menerapkan kode apa pun di sisi klien.
• Kekurangan:
  • Terikat ke satu domain. (Jadi, jika Anda memiliki aplikasi satu halaman yang membuat permintaan ke beberapa layanan, Anda dapat melakukan hal-hal gila seperti proxy terbalik.)
  • Rentan terhadap XSRF. Anda harus menerapkan tindakan ekstra untuk membuat situs Anda terlindungi dari pemalsuan permintaan lintas situs.
  • Dikirim untuk setiap permintaan, (bahkan untuk permintaan yang tidak memerlukan otentikasi).

Secara keseluruhan, menurut saya token memberi Anda fleksibilitas yang lebih baik, (karena Anda tidak terikat pada satu domain). Sisi negatifnya adalah Anda harus melakukan beberapa pengkodean sendiri.

• Token perlu disimpan di suatu tempat (penyimpanan lokal / sesi atau cookie)

• Token bisa kedaluwarsa seperti cookie, tetapi Anda memiliki kontrol lebih

• Penyimpanan lokal / sesi tidak akan berfungsi di seluruh domain, gunakan cookie penanda

• Permintaan Preflight akan dikirim pada setiap permintaan CORS

• Saat Anda perlu melakukan streaming sesuatu, gunakan token untuk mendapatkan permintaan yang ditandatangani

• Lebih mudah menangani XSS daripada XSRF

• Token dikirim pada setiap permintaan, perhatikan ukurannya

• Jika Anda menyimpan info rahasia, enkripsi token tersebut

• Token Web JSON dapat digunakan di OAuth

• Token bukanlah peluru perak, pikirkan kasus penggunaan otorisasi Anda dengan cermat

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Untuk Karyawan Google :

• JANGAN gabungkan statefulness dengan mekanisme transfer state

KEBERHASILAN

• Stateful = simpan info otorisasi di sisi server, ini adalah cara tradisional
• Stateless = menyimpan info otorisasi di sisi klien, bersama dengan tanda tangan untuk memastikan integritas

MEKANISME

• Cookie = tajuk khusus dengan perlakuan khusus (akses, penyimpanan, kedaluwarsa, keamanan, transfer otomatis) oleh browser
• Header Kustom = misalnya Authorization, hanya header tanpa perlakuan khusus, klien harus mengelola semua aspek transfer
• Lainnya . Mekanisme transfer lain dapat digunakan, misalnya string kueri adalah pilihan untuk mentransfer ID autentikasi untuk sementara waktu tetapi ditinggalkan karena ketidakamanannya

PERBANDINGAN STATEFULNESS

• "Otorisasi berstatus" berarti server menyimpan dan memelihara info otorisasi pengguna di server, menjadikan otorisasi sebagai bagian dari status aplikasi
• Ini berarti klien hanya perlu menyimpan "ID autentikasi" dan server dapat membaca detail autentikasi dari database-nya
• Ini menyiratkan bahwa server menyimpan kumpulan autentikasi aktif (pengguna yang masuk) dan akan menanyakan info ini untuk setiap permintaan
• "Otorisasi tanpa status" berarti server tidak menyimpan dan memelihara info autentikasi pengguna, server tidak tahu pengguna mana yang masuk, dan mengandalkan klien untuk menghasilkan info autentikasi
• Klien akan menyimpan info auth lengkap seperti siapa Anda (ID pengguna), dan mungkin izin, waktu kedaluwarsa, dll., Ini lebih dari sekadar ID auth, jadi diberi token nama baru
• Jelas klien tidak dapat dipercaya, sehingga data auth disimpan bersama dengan tanda tangan yang dihasilkan dari hash(data + secret key), di mana kunci rahasia hanya diketahui server, sehingga integritas data token dapat diverifikasi.
• Perhatikan bahwa mekanisme token hanya memastikan integritas, tetapi bukan kerahasiaan, klien harus mengimplementasikannya
• Ini juga berarti untuk setiap klien permintaan harus mengirimkan token lengkap, yang menimbulkan bandwidth ekstra

PERBANDINGAN MEKANISME

• "Cookie" hanyalah sebuah tajuk, tetapi dengan beberapa operasi yang dimuat sebelumnya di browser
• Cookie dapat disetel oleh server dan disimpan secara otomatis oleh klien, dan akan dikirim secara otomatis untuk domain yang sama
• Cookie dapat ditandai sebagai httpOnlymencegah akses JavaScript klien
• Operasi yang dimuat sebelumnya mungkin tidak tersedia di platform selain browser (mis. Seluler), yang mungkin memerlukan upaya ekstra
• "Header kustom" hanyalah header kustom tanpa operasi yang dimuat sebelumnya
• Klien bertanggung jawab untuk menerima, menyimpan, mengamankan, mengirimkan dan memperbarui bagian tajuk khusus untuk setiap permintaan, ini dapat membantu mencegah beberapa penyematan URL berbahaya sederhana

SUM-UP

• Tidak ada keajaiban, status auth harus disimpan di suatu tempat, baik di server atau klien
• Anda dapat menerapkan stateful / stateless dengan cookie atau header khusus lainnya
• Ketika orang berbicara tentang hal-hal itu, pola pikir default mereka sebagian besar adalah: stateless = token + tajuk khusus, stateful = auth ID + cookie; ini BUKAN satu-satunya pilihan yang mungkin
• Mereka memiliki pro dan kontra, tetapi bahkan untuk token terenkripsi Anda tidak boleh menyimpan info sensitif

Tautan

Saya yakin ada kebingungan di sini. Perbedaan yang signifikan antara otentikasi berbasis cookie dan apa yang sekarang dimungkinkan dengan Penyimpanan Web HTML5 adalah bahwa browser dibuat untuk mengirim data cookie setiap kali mereka meminta sumber daya dari domain yang menetapkannya. Anda tidak dapat mencegahnya tanpa mematikan cookie. Browser tidak mengirim data dari Penyimpanan Web kecuali kode di halaman mengirimkannya . Dan halaman hanya dapat mengakses data yang disimpannya, bukan data yang disimpan oleh halaman lain.

Jadi, pengguna khawatir tentang cara data cookie mereka digunakan oleh Google atau Facebook mungkin mematikan cookie. Namun, mereka memiliki lebih sedikit alasan untuk mematikan Penyimpanan Web (sampai pengiklan menemukan cara untuk menggunakannya juga).

Jadi, itulah perbedaan antara berbasis cookie dan berbasis token, yang terakhir menggunakan Penyimpanan Web.

Otentikasi berbasis token tidak memiliki kewarganegaraan, server tidak perlu menyimpan informasi pengguna dalam sesi tersebut. Ini memberikan kemampuan untuk menskalakan aplikasi tanpa khawatir di mana pengguna telah masuk. Ada afinitas Kerangka Server web untuk berbasis cookie sementara itu bukan masalah dengan berbasis token. Jadi, token yang sama dapat digunakan untuk mengambil sumber daya aman dari domain selain dari yang kita masuki yang menghindari otentikasi uid / pwd lainnya.

Artikel yang sangat bagus di sini:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Gunakan Token ketika ...

Federasi diinginkan. Misalnya, Anda ingin menggunakan satu penyedia (Token Dispensor) sebagai penerbit token, lalu menggunakan server api Anda sebagai validator token. Aplikasi dapat mengautentikasi ke Token Dispensor, menerima token, dan kemudian menyajikan token itu ke server api Anda untuk diverifikasi. (Sama halnya dengan Masuk dengan Google. Atau Paypal. Atau Salesforce.com. Dll)

Asynchrony diperlukan. Misalnya, Anda ingin klien mengirim permintaan, dan kemudian menyimpan permintaan itu di suatu tempat, untuk ditindaklanjuti oleh sistem terpisah "nanti". Sistem terpisah itu tidak akan memiliki koneksi sinkron ke klien, dan mungkin tidak memiliki koneksi langsung ke apotik token pusat. JWT dapat dibaca oleh sistem pemrosesan asinkron untuk menentukan apakah item pekerjaan dapat dan harus dipenuhi di lain waktu. Ini, sedikit banyak, terkait dengan gagasan Federasi di atas. Berhati-hatilah di sini: JWT kedaluwarsa. Jika antrian yang menahan item pekerjaan tidak diproses dalam masa JWT, maka klaim tidak lagi dipercaya.

Permintaan Cient Signed diperlukan. Di sini, permintaan ditandatangani oleh klien menggunakan kunci pribadinya dan server akan memvalidasi menggunakan kunci publik klien yang sudah terdaftar.

Salah satu perbedaan utama adalah bahwa cookie tunduk pada Kebijakan Asal yang Sama sedangkan token tidak. Ini menciptakan semua jenis efek aliran bawah.

Karena cookie hanya dikirim ke dan dari host tertentu, host tersebut harus menanggung beban otentikasi pengguna dan pengguna harus membuat akun dengan data keamanan dengan host tersebut agar dapat diverifikasi.

Token di sisi lain dikeluarkan dan tidak tunduk pada kebijakan asal yang sama. Penerbit bisa jadi siapa saja dan terserah pada tuan rumah untuk memutuskan penerbit mana yang harus dipercaya. Penerbit seperti Google dan Facebook biasanya dipercaya dengan baik sehingga tuan rumah dapat mengalihkan beban otentikasi pengguna (termasuk menyimpan semua data keamanan pengguna) ke pihak lain dan pengguna dapat mengkonsolidasikan data pribadi mereka di bawah penerbit tertentu dan tidak perlu mengingat sekelompok sandi berbeda untuk setiap host tempat mereka berinteraksi.

Hal ini memungkinkan skenario sistem masuk tunggal yang mengurangi keseluruhan gesekan dalam pengalaman pengguna. Secara teori, web juga menjadi lebih aman karena penyedia identitas khusus muncul untuk menyediakan layanan autentikasi alih-alih membuat setiap situs web ma dan pa menjalankan sistem autentikasi mereka sendiri, kemungkinan setengah matang. Dan karena penyedia ini mengeluarkan biaya untuk menyediakan sumber daya web yang aman bahkan untuk tren sumber daya yang sangat dasar menuju nol.

Jadi secara umum, token mengurangi gesekan dan biaya yang terkait dengan penyediaan otentikasi dan menggeser beban berbagai aspek web yang aman ke pihak terpusat yang lebih mampu menerapkan dan memelihara sistem keamanan.