Oauthlib: Client_secretとcode_verifier（PKCE）は安全に送信する必要があります

こんにちは@polamayster 、あなたは完全に正しいです。

RFCのセクションを追加して、実装方法を指定しています。

OAuth2.0 RFCのセクション：

https://tools.ietf.org/html/rfc6749#section -2.3.1

2.3.1.  Client Password
   Clients in possession of a client password
   MAY use the HTTP Basic authentication scheme (..) 

   Alternatively, the authorization server
   MAY support including the client credentials in the request-body (..)

   The parameters can only be transmitted in the request-body and
   MUST NOT be included in the request URI.

PKCE RFCのセクション：

https://tools.ietf.org/html/rfc7636#section -4.5

4.5.  Client Sends the Authorization Code and the Code Verifier to the
      Token Endpoint
    In addition to the parameters defined in the OAuth 2.0 Access
    Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:

   code_verifier
      REQUIRED.  Code verifier

https://tools.ietf.org/html/rfc6749#section -4.1.3

4.1.3.  Access Token Request

   The client makes a request to the token endpoint by sending the
   following parameters (..) in the HTTP request entity-body:

ですから、私はこの問題の妥当性について疑いの余地はありません。 どんなPRでも大歓迎です！

私はこれを引き受けることに興味があります。 すぐにプルリクエストを送信します。

この動作は、資格情報を期待するリクエストまたは一般的なリクエストに対してのみ適用する必要がありますか？

私の理解では、 oauthlib.common.Requestクラスには__getattr__メソッドと_paramsディクショナリ（クエリ文字列と本文のパラメータから更新）、およびclient_secretにアクセス/取得しようとするすべてのリクエストがありclient_secretまたはcode_verifierは、本文またはヘッダー、あるいはその両方でのみ検索する必要があります（おそらく、機密データの検索用に個別のプロパティを使用するのが理にかなっています）

なるほど、今日はPRを提出します

2019年4月20日土曜日、午後12時38分Bohdan < [email protected]は次のように書いています。

私の理解では、oauthlib.common.Requestクラスには__getattr__があります
メソッドと_paramsディクショナリ（クエリ文字列と本文から更新）
パラメータ）およびclient_secretにアクセス/取得しようとするリクエストまたは
code_verifierは、本文やヘッダーのみを検索する必要があります（おそらく
機密データ検索用の個別のプロパティは理にかなっています）

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANCNFSM4HHD7NNQ
。

私の理解では、 oauthlib.common.Requestクラスには__getattr__メソッドと_paramsディクショナリ（クエリ文字列と本文のパラメータから更新）、およびclient_secretにアクセス/取得しようとするすべてのリクエストがありclient_secretまたはcode_verifierは、本文またはヘッダー、あるいはその両方でのみ検索する必要があります（おそらく、機密データの検索用に個別のプロパティを使用するのが理にかなっています）

それで、チェックはURLが設定されているときではなく、属性アクセス時に行われるべきですか？ リクエスト属性が初期化時に一度だけ設定されている場合、すべての属性アクセスではなく、その場でチェックを実行できます。 各属性アクセスで引き続きチェックを実行する必要があると思われる場合はお知らせください。

この問題はより大きく、 /tokenエンドポイント全体に当てはまります。 このエンドポイントは、URLのパラメータを受け入れてはなりません（MUSTNOT）。 それは許されてはならない。

イントロスペクションエンドポイントも適格だと思います。 IIRCによると
HTTP仕様、POSTリクエストは常にクエリパラメータを無視する必要があります。 もしも
私たちはそれを強制し、影響を与えることなくすべての問題を自動的に解決します
有効なユースケース。 他のHTTP動詞がどのように動作するのかわかりません
しかし、私はPOST1でかなり確信しています。 それが正しいかどうか誰かが確認できますか
向かう方向は？

>>

すべてのPOSTのすべてのクエリパラメータを拒否することは、魅力的な優れたショートカットです。 ただし、oauthlibのResourceEndpointと、一部のユーザーが引き続きクエリ引数をURLに追加できるという事実が心配です（推奨されていませんが、技術的には可能です）。

リソースエンドポイントに関する懸念についてもう少し詳しく説明していただけますか？

私の見方では、POSTリクエストはフォーム送信またはAPIのいずれかを介して行われます
呼び出し（明示的なコードの記述）。 なぜ誰かが部分的に追加するのかわかりません
クエリパラメータとしてのデータと投稿データとしての部分的。 実際、より簡単です
どちらかに完全にコミットします。
実際、ライブラリを使用してリクエストを行う場合は、はるかに簡単です。
分割するのではなく、すべてを投稿本文として追加します。

説明エラーが表示された場合にPOSTにクエリパラメータを追加するユーザーは、
すばやく自己修正できるはずです。

または、適用すると発生するミックスインまたはデコレータを作成することもできます
クエリパラメータを使用したPOSTリクエストのエラー。

これに対する別の可能な解決策があります。 エンドポイントの場合（ AuthorizationEndpoint 、 IntrospectEndpoint 、 RevocationEndpoint ）; リクエストメソッドがPOSTの場合、それぞれのリクエスト検証メソッドにクエリパラメータのチェックを追加できます。 （ TokenEndpoint 、 MetadataEndpoint ）の場合、応答生成メソッドにチェックを追加できます。
または、一貫性を保つために、それらすべての応答生成メソッド内にチェックメカニズムを追加することもできます。 それは良い考えのように聞こえますか？

_request_検証メソッドを使用することが望ましいと思います。
POSTがTokenEndpoint 、 IntrospectEndpoint 、およびRevocationEndpoint専用であることを知っています。 その他はGET ： AuthorizationEndpoint 、 MetadataEndpointです。

ただし、一般的なコメント：機密フィールドに焦点を当てる必要があるか（ブラックリストの維持など）、またはすべてのOAuth2パラメーターを拒否する必要があります（クエリURIにNONEを含める必要がありますか？）

理想的には、クエリURIにNONEが必要です。 私はそうではなかったので、私はブラックリストに行きました
いくつかの既存のユースケースを破っている可能性があるかどうかを確認してください。 OAuth2がないだけではありません
パラメータは許可されていますが、クエリパラメータはまったく許可されていません。

>>

チェックをリクエストからエンドポイントに移動した場合、それらのエンドポイントのすべてのクエリパラメータを無効にしても問題は発生しません。

それでは、これらの正確なエンドポイントですべてのクエリパラメータを無効にします。 と
また、httpメソッドをPOSTに制限していますよね？

https://github.com/oauthlib/oauthlib/pull/667で修正済み

この変更の理由は理解していますが、これはクエリパラメータとしてclient_secretを送信するクライアントにとっては重大な変更のようです。 下位互換性またはメジャーバージョンのバンプを期待していました。 この動作は意図されたものですか？

現在django-oauth-toolkitを使用しており、クライアントはクエリとしてusername 、 password 、 client_secret 、 client_id 、 grant_typeを送信していますパラメータ。 すべてをPOSTパラメータとして送信するように切り替えると、エラーunsupported_grant_typeます。

POSTのクエリのサポートは、望ましい動作よりも副作用です。 クライアントが壊れることを理解しているので、3.1未満に特定することをお勧めします
また、セキュリティ上の懸念があるため、できるだけ早くアップグレードすることを検討してください（秘密はログ、プロキシ、複数の意図しない場所に表示されます）。