Oauthlib: エラー応答時の無効なHTTPステータス

仕様では、401は無効なクライアントエラーで使用される可能性があり、認証ヘッダーフィールドを介して認証が行われたときに使用する必要があると記載されています。 oauthlibは現在、仕様の要求に応じて「WWW-Authenticate」ヘッダーフィールドを応答に含める必要があることを示唆するものは何もありません。 このエラーのために401を維持することは問題ないと思いますが、例外にヘッダーの提案を追加する必要があります。

他の点に関しては、仕様は401を使用できると明示的に述べていないため、おそらく400に変更することを検討する必要があります。ただし、無効な許可と特に許可されていないクライアントエラーの両方で401を使用する方が適切と思われます。

@ asteinlein 、 @ lepture 、 @ masciの考え？

@ ib-lundgrenこんにちは-この問題に遭遇したばかりで、チャイムを鳴らしたいと思います。仕様を読んだり、他の回答を調べたりすると、IMO a400が正しい応答です。

まず、仕様：

承認サーバーはHTTP400（不正な要求）で応答します
ステータスコード（特に指定のない限り）および以下が含まれます
応答のあるパラメーター：

400の要件にMUSTはありませんが、MAYもありません。

第二に、私がこれに遭遇した理由は、私のクライアントの太陽JDKのある種のバグによるものでした（ここを参照してください：http：//stackoverflow.com/a/7524681/1137254）

基本的に、私のクライアントのHTTPスタックは401の接続を早期に閉じますが、上記のOAuthスタック（google-http-oauth-client）は結果の読み取りと解析を続行しようとします。 これは、401の周りの定義と期待に従ってOpenJDKに書き込まれたと思います（更新：実際には「ストリーミング」モードと関係があります）。 IMO OpenJDKも間違っており、/ tokenエンドポイント要求中に「invalid_client」401を取得した場合、これと同じ問題が発生すると思います。

ここに正しいエラーコードである400への別の投票を追加します。 以前はモバイルアプリからのoauth2認証にdjango-oauth2-providerを使用していましたが、この場合は400を返しました。 新しいバージョンのDjangoにアップグレードするためにdjango-oauth-toolkit（oauthlibを使用）に切り替える場合、モバイルアプリを正しく機能させるために、トークンリクエストビューをハックして400を返す必要がありました。

仕様の作成者の1人は、トークンを要求するときに無効な認証クレデンシャルに対して400が意図された応答であると具体的に述べており、その理由は次のとおりです。https ：//www.ietf.org/mail-archive/web/oauth/current/msg02127

そして、これらの状況で401を使用してoauthlibに対処するのに問題があるプロジェクトの別の例を次に示します。

400の場合は+1

400に投票する

私はこの古いスレッドを復活させ、上記の変更を加えてPRを開始します。

これを進める前に、過去に起こった議論を要約したいと思います。

• OAuth2.0 RFC6749ワーキンググループは、エラーHTTPステータスに401ではなく400を採用することを決定しました。これは、 WWW-Authenticateを設定する必要があり、すべてのエラー応答で常に可能であるとは限りません。
• @asteinleinはhttps://github.com/oauthlib/oauthlib/pull/247でPRを提案し、oauthlibのエラーを400から401に変更しました。これは、_一部のクライアントが承認に関連するAPI呼び出しに401を期待しているように見えるためです_。 それは真実でなければなりませんでしたが、どのクライアントが壊れたかはわかりません。
• サードパーティのライブラリでいくつかのバグがポップアップするhttps://github.com/oauthjs/angular-oauth2/issues/31https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https ：// github .com / oauthjs / angle-oauth2 / issues / 36 。 現在、問題はすべてクローズされています。
• 現在のスレッドとRFC6749＃5.2の全体的なコンセンサスは、oauthlib内のすべての401は400でなければならないということです。 ただし、 401の場合は2つあります。

1. invalid_client 、HTTP認証を使用する場合は401である必要があり、そうでない場合は401である可能性があります。
2. invalid_token 、ここで$ 401である必要があります。

いずれの場合も、 401を使用する場合は、 WWW-Authenticateを設定する必要があります（ RFC2616 ）。

その他のOAuth2.0実装

最も一般的なOAuth2.0実装の概要は、全体的なコンセンサスに似ています。

• Googleは400 so-question / so-questionを返します。
• Salesforceは400 salesforce-forumを返します。
• Azurは$ WWW-Authenticate azur-docsで401を返します。
• AWSは400 aws-cognito-docsを返します。 HTTP認証を使用する場合、RFCの「 MUST 」を401に分割しました。

結論

RFCに合わせる必要がありますが、実装を壊さないために、これらの変更を2.xxバージョンに含めてはならず、3.xxまで待ちます。

お気軽にご参加ください。

PR＃247をプッシュした理由/クライアントを思い出せませんが、これを元に戻す理由を確認して理解しています。 @JonathanHuotのすばらしい調査に感謝します。これを3.xで行うのが、最善のアプローチのように思えます。

＃561 / oauthlib> = 3.0.0で修正

上記のRFCによると、無効なクライアントもステータス400を返す必要がありますが、パッケージにはまだ401が含まれています

こんにちは@ esfandiaryfard 、RFCの正確なテキストを指摘できますか？ ありがとう！