Haruskah cookie digunakan dalam API RESTful?

Saya secara khusus tertarik pada bagaimana pengguna melakukan operasi yang diautentikasi / diautentikasi pada API web.

Apakah cookie autentikasi kompatibel dengan filosofi REST, dan mengapa?

web-applications web-services rest

— Brandon Linton
sumber

duplikat yang tepat dari otentikasi yang tenang

kemungkinan duplikat arsitektur Perangkat Lunak untuk otentikasi / akses-kontrol layanan web REST

— FrustratedWithFormsDesigner

@JarrodRoberson Pemahaman saya adalah bahwa jawaban di situs lain tidak akan memenuhi syarat sebagai duplikat di sini

— Tom Squires

@JarrodRoberson berdasarkan FAQ masing-masing situs, saya berpendapat bahwa pertanyaan tersebut adalah milik situs ini dan bukan Stack Overflow. Saya tertarik dengan metodologi desain / filosofi dan pengorbanan mengenai aspek arsitektur RESTful ini. Stack Overflow dimaksudkan untuk pertanyaan implementasi, di mana situs ini lebih tentang metodologi desain dan pengorbanan.

— Brandon Linton

Saya setuju dengan @BrandonLinton di sini, pertanyaannya terlalu luas untuk Stackoverflow, itu adalah tentang arsitektur dan metodologi desain. OP menginginkan praktik terbaik dan pola, saran, dan gotcha - bukan jawaban spesifik - karenanya tidak ada bahasa yang ditentukan. Oleh karena itu, miliknya di sini.

— dooburt

Jawaban:

Layanan RESTful yang ideal memungkinkan klien (yang mungkin bukan di browser) untuk melakukan tugas yang diperlukan dalam satu permintaan ; karena keadaan penuh yang diperlukan untuk melakukan itu dipegang oleh klien, bukan server. Karena klien memiliki kontrol penuh atas negara, ia dapat membuat negara sendiri (jika itu sah), dan hanya berbicara dengan API untuk "menyelesaikannya".

Membutuhkan cookie dapat membuat hal itu sulit. Untuk klien selain browser, mengelola cookie adalah ketidaknyamanan yang cukup besar dibandingkan dengan permintaan kueri, header permintaan biasa atau badan permintaan. Di sisi lain, Di browser, menggunakan cookie dapat membuat banyak hal menjadi lebih sederhana.

Jadi API mungkin pertama-tama mencari di Authorizationheader untuk data otentikasi yang diperlukan, karena itu mungkin tempat di mana klien non-browser akan lebih suka untuk meletakkannya, tetapi untuk menyederhanakan dan merampingkan klien berbasis browser, mungkin juga memeriksa cookie sesi untuk sisi server masuk, tetapi hanya jika Authorizationheader biasa tidak ada.

Contoh lain mungkin permintaan kompleks yang biasanya membutuhkan banyak parameter yang ditetapkan. Klien non-interaktif tidak akan kesulitan mengacak semua data itu menjadi satu permintaan, tetapi antarmuka berbasis formulir HTML mungkin lebih suka memecah permintaan menjadi beberapa halaman (sesuatu seperti set halaman 'penyihir') sehingga pengguna tidak disajikan dengan opsi yang tidak berlaku berdasarkan pilihan sebelumnya. Semua halaman perantara dapat menyimpan nilai dalam cookie sisi klien, sehingga hanya halaman terakhir, di mana pengguna benar-benar mengirimkan permintaan, memiliki efek samping server sama sekali. API dapat mencari atribut yang diperlukan di badan permintaan, dan kembali ke melihat cookie jika parameter yang dibutuhkan tidak ada.

Edit: di RE ke komentar @ Konrad di bawah ini:

Token dalam perbandingan lebih sulit diterapkan terutama karena Anda tidak dapat dengan mudah membatalkan token tanpa menyimpannya di suatu tempat.

er ... Anda memvalidasi cookie di sisi server, bukan? Hanya karena Anda memberi tahu browser untuk membuang cookie setelah 24 jam, bukan berarti cookie akan dihapus. Cookie itu dapat disimpan oleh pengguna yang sangat teknis dan digunakan kembali lama setelah "kedaluwarsa".

Jika Anda tidak ingin menyimpan data sesi di sisi server, Anda harus menyimpannya di token (cookie atau lainnya). Token autentik berisi diri sendiri kadang-kadang disebut Macaroon. Bagaimana ini dilewatkan antara klien dan server (apakah dengan cookie, sebagai header tambahan, atau dalam entitas permintaan itu sendiri) benar-benar independen dari mekanisme otentikasi itu sendiri.

— SingleNegationElimination
sumber

+1, saya pasti menyukai kepraktisan menggunakan tajuk Otorisasi tetapi "mundur" ke cookie tergantung pada apa yang paling cocok untuk klien.

— Brandon Linton

Saya tidak setuju dengan "Untuk klien selain browser, mengelola cookie adalah ketidaknyamanan yang cukup besar ...". Sebagian besar pustaka klien HTTP mendukung cookie, misalnya, dengan HttpClient.NET Anda dapat menggunakan cookie tanpa masalah dan Anda tidak perlu memikirkannya. Token dalam perbandingan lebih sulit diterapkan terutama karena Anda tidak dapat dengan mudah membatalkan token tanpa menyimpannya di suatu tempat.

— Konrad

@ Konrad hanya karena mudah di beberapa klien non-browser tidak berarti itu mudah di semua dari mereka. Tidak apa-apa jika Anda hanya perlu mendukung klien tertentu yang kebetulan Anda gunakan, tetapi saya menafsirkan pertanyaannya adalah tentang publik yang menghadapi API. dalam curlatau wget, mengelola cookie sangat merepotkan dan Anda benar-benar harus memikirkannya banyak. Saya membalas poin Anda yang lain dengan mengedit jawaban saya.

— SingleNegationElimination

Berhati-hatilah karena hanya menerima cookie akan membuka kerentanan CSRF. Lihat juga security.stackexchange.com/a/166798

— Michael Osl

Ya dan Tidak - Tergantung cara Anda menggunakannya.

Cookie jika digunakan untuk mempertahankan keadaan klien di klien, untuk klien, klien dan klien maka mereka tenang.

Jika Anda menyimpan status server ke cookie, maka pada dasarnya Anda hanya memindahkan beban ke klien - yang tidak tenang.

Jadi apa saja contohnya?

Tenang:

Detail otentikasi atau 'masuk' agak banyak
halaman atau tempat terakhir dilihat dalam aplikasi dll

Tidak Tenang:

Menyimpan informasi sesi

Ketenangan berasal dari kewarganegaraan - dari server. Klien dapat mempertahankan status aplikasi dan mengirimkannya ke server untuk mengatakan di mana mereka berada sehingga server dapat memutuskan ke mana harus pergi dari sana. Pada dasarnya sesi / negara bagian membutuhkan data historis dan bergantung pada permintaan sebelumnya sehingga untuk berbicara, aplikasi yang tenang idealnya tidak (Ini tidak layak untuk memiliki aplikasi 100% murni yang tenang jika Anda akan memiliki layar login :)

— PhD
sumber

Jika Anda menyimpan bendera "isLoggedIn" pada klien, Anda mungkin juga tidak menggunakan otentikasi sama sekali.

— tdammers

Ini jelas masuk akal - menyimpan sisi aplikasi negara klien tidak akan konsisten dengan REST, tetapi informasi klien yang digunakan untuk mewakili itu sendiri tampaknya baik-baik saja.

— Brandon Linton

Saya ingin menambahkan bahwa memasukkan informasi autentikasi ke cookie membuka kemungkinan serangan pemalsuan permintaan lintas situs. Ada beberapa cara yang lebih baik, saya sarankan menyalin Amazon: docs.aws.amazon.com/AmazonS3/latest/API/…

— Vandermeer

@tdammers bagaimana dengan jika bendera "isLoggedIn" dalam JWT? Maka itu harus aman, asalkan JWT dikeluarkan dan diverifikasi dengan benar.

— Aaron J Spetner

@AaronJSpetner: Jangan gunakan JWT untuk sesi .

— tdammers

Seseorang dapat menggunakan cookie. REST memungkinkan mereka.

REST mensyaratkan bahwa setiap informasi sesi disimpan di sisi klien, tetapi ketika datang ke otentikasi, beberapa informasi harus tetap di sisi server untuk alasan keamanan.

Dari salah satu posting blog saya , ada kesepakatan umum bahwa data otentikasi dianggap di luar ruang lingkup mengenai REST. Oleh karena itu, tidak masalah bagi server untuk menyimpan sebagian data sesi ini di pihak mereka.

— Jérôme Verstrynge
sumber