Oauthlib: Status HTTP tidak valid pada respons kesalahan

Spesifikasi menyebutkan bahwa 401 dapat digunakan dengan kesalahan klien yang tidak valid dan harus digunakan ketika otentikasi dilakukan melalui bidang header otorisasi. Meskipun oauthlib saat ini tidak melakukan apa pun untuk menyarankan bahwa bidang tajuk 'WWW-Otentikasi' harus disertakan dalam respons sesuai kebutuhan spesifikasi. Saya rasa menyimpan 401 untuk kesalahan ini tidak masalah, tetapi kita harus menambahkan saran tajuk ke pengecualian.

Mengenai yang lain, spesifikasi tidak secara eksplisit mengatakan bahwa 401 dapat digunakan dan dengan demikian kami mungkin harus mempertimbangkan untuk mengubah ke 400. Namun tampaknya lebih sesuai dengan 401 dalam hibah yang tidak valid dan terutama kesalahan klien yang tidak sah.

@asteinlein , @lepture , @masci pikiran?

@ib-lundgren Hai - baru saja menemukan masalah ini dan ingin ikut campur. Dari membaca spesifikasi dan melihat-lihat jawaban lain, IMO a 400 adalah respons yang benar.

Pertama, speknya:

Server otorisasi merespons dengan HTTP 400 (Permintaan Buruk)
kode status (kecuali ditentukan lain) dan termasuk yang berikut:
parameter dengan respons:

Tidak ada HARUS dalam 400 persyaratan, tetapi tidak ada MUNGKIN juga.

Kedua, dan alasan saya menemukan ini adalah melalui semacam bug di bawah sinar matahari JDK pada klien saya (lihat di sini: http://stackoverflow.com/a/7524681/1137254 )

Pada dasarnya, tumpukan HTTP klien saya akan menutup koneksi lebih awal untuk 401, tetapi tumpukan OAuth di atas (google-http-oauth-client) akan mencoba untuk terus membaca dan mengurai hasilnya. Saya pikir ini ditulis ke dalam OpenJDK sesuai definisi dan harapan sekitar 401 (PEMBARUAN: ini sebenarnya berkaitan dengan mode 'streaming'). IMO OpenJDK juga salah dan saya pikir saya akan mengalami masalah yang sama jika saya mendapatkan "invalid_client" 401 selama permintaan titik akhir /token.

Menambahkan suara lain untuk 400 menjadi kode kesalahan yang benar di sini. Kami dulu menggunakan penyedia django-oauth2 untuk otentikasi oauth2 dari aplikasi seluler, dan itu mengembalikan 400 dalam kasus ini. Saat beralih ke Django-oauth-toolkit (yang menggunakan oauthlib) untuk meningkatkan ke versi Django yang lebih baru, kami harus meretas tampilan permintaan token untuk mengembalikan 400 sebagai gantinya untuk menjaga aplikasi seluler bekerja dengan benar.

Berikut salah satu penulis spesifikasi yang secara khusus menyatakan bahwa 400 adalah respons yang dimaksudkan untuk kredensial otentikasi yang tidak valid saat meminta token, dan alasannya: https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

Dan inilah contoh lain dari proyek yang mengalami masalah dalam mengatasi oauthlib menggunakan 401 dalam situasi ini.

+1 untuk 400

Suara untuk 400

Saya menghidupkan kembali utas lama ini & memulai PR dengan perubahan yang disarankan di atas.

Sebelum membuat kemajuan dalam hal ini, saya ingin meringkas diskusi yang terjadi di masa lalu.

• Kelompok kerja OAuth2.0 RFC6749 memutuskan untuk mengadopsi 400 untuk status HTTP kesalahan alih-alih 401, karena memerlukan WWW-Authenticate untuk disetel, dan itu tidak selalu memungkinkan dalam semua tanggapan kesalahan.
• @asteinlein mengusulkan PR di https://github.com/oauthlib/oauthlib/pull/247 untuk mengubah kesalahan oauthlib dari 400 menjadi 401, karena _beberapa klien tampaknya mengharapkan 401 untuk panggilan API yang terkait dengan otorisasi_. Meskipun itu harus benar, kami tidak tahu klien mana yang rusak.
• Beberapa bug muncul di perpustakaan pihak ke-3 https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https://github .com/oauthjs/angular-oauth2/issues/36 . Masalah semua ditutup sekarang.
• Konsensus keseluruhan dari utas saat ini, dan juga RFC6749#5.2 , adalah bahwa semua 401 di oauthlib harus 400 . Namun, kami memiliki dua kasus dengan 401 :

1. invalid_client , di mana itu HARUS 401 jika otentikasi HTTP digunakan, selain itu MUNGKIN 401 .
2. invalid_token , di mana itu HARUS 401 .

Bagaimanapun, jika 401 digunakan, WWW-Authenticate HARUS disetel ( RFC2616 ).

Implementasi OAuth2.0 lainnya

Ikhtisar singkat tentang implementasi OAuth2.0 yang paling umum mirip dengan konsensus keseluruhan:

• Google mengembalikan 400 so-question / so-question .
• Salesforce mengembalikan 400 salesforce-forum .
• Azur mengembalikan 401 dengan WWW-Authenticate azur-docs .
• AWS mengembalikan 400 aws-cognito-docs . Mereka memecahkan " HARUS " dari RFC menjadi 401 ketika otentikasi HTTP digunakan.

Kesimpulan

Kami harus menyelaraskan dengan RFC, namun untuk tidak merusak implementasi apa pun, kami tidak boleh menyertakan perubahan ini dalam versi 2.xx, tetapi tunggu hingga 3.xx

Silakan, jangan ragu untuk ikut campur.

Saya tidak dapat mengingat alasan/klien yang membuat saya mendorong PR #247, tetapi saya melihat dan memahami alasan untuk mengembalikan ini. Terima kasih atas penelitian yang luar biasa @JonathanHuot , dan melakukan ini dalam 3.x terdengar seperti pendekatan terbaik.

Diperbaiki di #561 / oauthlib>= 3.0.0

menurut RFC ini yang disebutkan di atas klien yang tidak valid juga harus mengembalikan status 400 tetapi dalam paket masih 401

Hai @esfandiaryfard , bisakah Anda menunjukkan teks RFC yang tepat? Terima kasih!