Oauthlib: クライアントWebアプリケーションはclient_idを送信しなくなりました

私の最初の考えはの変化戻すことですprepare_request_body 、デフォルトで、使用するself.client_idに設定されたWebApplicationClientコンストラクタを。
次に、インラインドキュメントをdequationで変更して、 &client_id=xxをprepare_request_body出力に追加する必要があります。

最後に、元の修正を置き換えるために、引数からclient_idを削除し、 include_client=True/Falseようにprepare_request_body新しい引数を追加して、両方にclient_id追加することをお勧めします。本文にclient_secretを含めるか、両方を含めないでください。

考え？

@Diaoul @ skion @ thedrowを突く

どうですか：

引数からclient_idを削除し、include_client = True / Falseのようなprepare_request_bodyに新しい引数を追加して、client_idとclient_secretの両方を本文に追加するか、両方を含めないことをお勧めします。

ありがとう

私は実際に私のテストの1つでこれと同じ問題を引き起こしましたが、requests / oauthlibに対してここに提出しました： https ：

問題は実際にはrequests_oauthlibのせいだと思います。 彼らのドキュメント（実際には、ページをロードしたときのドキュメント全体の最初の例）は、 OAuth2Sessionコンストラクターでclient_idを指定することをサポートしています。 行200のロジックは、kwargsからclient_idをプルしますが、すでに構築されているWebApplicationClientインスタンスからプルするためのフォールバックはありません。

@jvanasco 、現在の問題＃585は、requests-oauthlibのみで修正するか、oauthlibのPR＃505を元に戻すことで修正できます。 ただし、 https： //github.com/oauthlib/oauthlib/pull/505#issuecomment-351221107のコメントで@skionが言及した動作を修正するソリューションはありません。

仕様によれば、client_idパラメーターは認証されていないクライアントに送信する必要がありますが、機密クライアントのトークン要求本文では送信しないことが望ましいです。その場合、クライアントを認証するための推奨メカニズムはHTTP基本認証を介して行われます。 ただし、WebApplicationクラスには常にそれが含まれ（一部のサーバーが破損します）、それを削除するメカニズムは提供されません。

Oauthlibは、リクエストに対してエレガントでシンプルな方法を提供する必要があります-oauthlibは問題を解決します。 この議論で解決策を見つけることができれば、それは素晴らしいことです。 それは巨大なブロッカーだからです。

prepare_request_body()ヘルプでclient_id=Falseを許可して、client_idが送信されないことを示しますか？ たとえそうだとしても、それは126行目近くのこの醜さにつながるでしょう：

client_id = None if client_id=False else self.client_id

ああ、分かった。

client_idを送信する必要がある場合と送信しない場合の既存の単体テストはありますか？ そうでない場合、誰かがそれを生成するために使用できるリストを持っていますか？ 私はこれとrequests-oauthlibを修正することを喜んで受け入れます、なぜならそれは今私の仕事のいくつかをブロックしているからです。

@JonathanHuot

引数からclient_idを削除し、include_client = True / Falseのようなprepare_request_bodyに新しい引数を追加して、client_idとclient_secretの両方を本文に追加するか、両方を含めないことをお勧めします。

これを読み返して、私は実際にあなたの提案がとても好きです。 関数はすでに**kwargs取るので、おそらくそれを壊さない方法でやることはできます。

注：

本体にclient_idとclient_secretの両方を追加します

これはパブリッククライアントIIUCに関するものなので、 client_secretが関係しているとは思いません。 client_idが本体に追加されているだけですか？ その場合、新しいパラメータの名前をinclude_client_id=True/False変更することも検討します。

その場合、新しいパラメーターの名前をinclude_client_id = True / Falseに変更することも検討します。

それはそう ！ client_secretは、 WebApplicationClient存在しないため、関与しません。

@ jvanasco 、PRをしたいのなら、変更は次のようにすべきだと思います。
1）https://github.com/oauthlib/oauthlib/pull/505を元に戻します
2）を変更し、署名prepare_request_body()削除するclient_idし、追加include_client_id=True/False （ True （デフォルト）：それは追加self.client_id ）

次に、requests-oauthlibは、https：//github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L196-L211で次のいずれかを選択できます。
A）本文にclient_idのみを含める

self._client.prepare_request_body(..)

B） client_idとclient_secretをauth含め、本文には含めない（RFC推奨ソリューション）

self._client.prepare_request_body(include_client_id=False, ..)
auth = requests.auth.HTTPBasicAuth(client_id, client_secret)

C）本文にclient_idとclient_secretを含める（RFC代替ソリューション）

self._client.prepare_request_body(client_secret=client_secret, ..)

今日は両方のプロジェクトのPRを生成します。

OAuthlibのPRとテストはほぼ完了しています。 でも質問があります...

client_idまだkwargとして許可されるべきですか？ これは部分的に下位互換性のためですが、エッジケースのためでもあります。 このメソッドはやや壊れていたので、意図したとおりに機能させる（ prepare_request_body self.client_idをオーバーライドできるようにするなど）か、誤った使用法で例外を発生させる（発生させるなど）価値があると思います。 client_idが提供されているが、 self.client_id一致しない場合はエラーになります）。

client_idを別の値でオーバーライドする方法がわからないため、例外が異なる場合は例外を発生させることに投票します。

さらに、 client_idがkwargとして提供された場合、 DeprecationWarningログに記録する必要がありますか？

PR＃593を提出しました。 client_idが送信されるとDeprecationWarningが発生し、 self.client_idと異なる場合はValueErrorが発生します。 詳細な3つのシナリオ@JonathanHuotへの準拠を確認する新しいテストもあります。

リクエストに関する最初の問題に遭遇しました-いくつかのテストを書いているときにoauthlibPR候補

それは、常に起動しますprepare_request_bodyしてusername=username, password=password 。 これは間違っているようです。 ここにいる誰かがRFCに精通していて、次の答えを知っていることを願っています。

1. username + password request.bodyのパラメータにする必要がありますか？
2. username + passwordがHTTP基本認証ヘッダーに表示される場合、それらをリクエスト本文に複製する必要がありますか？
3. username + password本文パラメーターとクライアントの詳細を含むHTTPBasicAuthヘッダーの両方を持つことは可能ですか？

これに遭遇してくれてありがとう。

1. usernameとpasswordは、常にリクエストの本文に存在するのみ使用する必要があります。 これらを他の付与（暗黙的、コード、クライアント資格情報）に使用してはなりません。
2. HTTP基本認証は、クライアントの資格情報ではオプションです（機密クライアント、つまりclient_secret使用する場合に推奨されます）。 ユーザーの資格情報は、HTTP基本認証に含まれていてはなりませ
3. はい

ありがとう。 2つのことを明確にするために、私が5歳のように遠慮なく私に話してください。 私はこれとテストが正しく行われることを確認したいと思います：

1. ユーザー名とパスワードは、それらを必要とする特定の種類の付与でのみ使用されます。 使用する場合、それらはリクエスト本文にのみ存在する可能性があります。

それらが明示的に指定されていない限り、それらは存在すべきではありません、正しいですか？

1. Http基本認証がクライアントの資格情報のみを対象としている場合、既存のrequests-oauthlibには、ユーザー名とパスワードの組み合わせから基本認証を生成するブロックを含めるべきではありません。

冗長で、これらの小さな詳細に執着していることをお許しください。 jが正しい動作を取得し、別の回帰が発生しないことを確認するテストを記述できることを確認したいだけです。

@ jvanasco 、OAuth2 RFCについてはわかりますが、 requests-oauthlibとflask-oauthlibどのように組み合わされているかわかりません。

1. はい

正しい。

1. はい、AFAIUにはこのブロックを含めるべきではありませんhttps://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L207-L211 。

私の理解ですが、現場の現実と照合するのは良いことです。 つまり、requests-oauthlibとさまざまなパブリックプロバイダーの経験。 複数の要求-oauthlibの議論https://github.com/requests/requests-oauthlib/issues/218 、 https://github.com/requests/requests-oauthlib/issues/211 、 https://github.com/requests / requests-oauthlib / issues / 264 、すでに発生しています。

client passwordとclient secret間で混乱があったと思いますが、これは実際にはまったく同じことを表す2つの表現です。
https://github.com/requests/requests-oauthlib/pull/206の背後にある理論的根拠に従うと、PRのコンテンツはHTTPAuth(username, password)追加するようなものではなく、 HTTPAuth(client_id, client_secretであるはずです。 （クライアントのパスワード）。

リクエストに参加した@ Lukasa 、 @ chaosct 、 @ ibuchananを突く-oauthlibの議論。

素晴らしい！ 本当にありがとう。 それが起こっていると思いましたが、確認したかったのです。

私は今、リクエストをどのように構成したいかを知っていると思います。 私はメインリクエストプロジェクトにいくつかのコミットを持っているので、メンテナがPRと機能で何を見たいかを知っています。

1. ユーザー名とパスワードは、それらを必要とする特定の種類の付与でのみ使用されます。 使用する場合、それらはリクエスト本文にのみ存在する可能性があります。

はい、最初の部分です。特定の種類の助成金のみがそれらを必要とします。 しかし、リクエスト本文でそれらを送信することについての2番目の部分では、仕様は次のように述べています。

リクエスト本文にクライアントの資格情報を含める
2つのパラメーターの使用は推奨されません
直接利用できないクライアントに限定する必要があります
HTTP基本認証スキーム..

しかし、サーバーの場合、次のようになります。

承認サーバーは、以下を含むサポートを行う場合があります
リクエストボディのクライアントクレデンシャル...

準拠しているクライアントは、リクエスト本文で資格情報を送信しません。
ただし、一部実装されているサーバーの場合、リクエスト本文でのみ受け入れます。
正しく思い出せば、私のPRは、認証ヘッダーを追加することでこの混乱を解決しました。
したがって、クライアントは両方を送信します。

@JonathanHuotは2点目については正しいと

こんにちは@ibuchanan 、あなたが参照している引用符は用語client credentialsます。 クライアントとリソース所有者（実際のユーザー）を混在させないように十分に注意する必要があります。

役割はここで明確に説明されていますrfc6749＃1.1 。
このclient credentialsはclient_idとclient_secretをusernameとpasswordます。 それらは互換性がありません。

したがって、これらのロールでRFCを読み取ることは、準拠するクライアントがHTTP Basicでクライアントクレデンシャル（ client_id 、 client_secret ）を送信する必要があり、ユーザークレデンシャル（ username 、 passwordリクエスト本文のrfc6749＃4.3.2を参照してください。

client_idがリクエストに含まれている場合、一部のサーバーはリクエスト（400）を拒否します
体。 デフォルトは仕様で推奨されているものでなければならないと思います。

Ok。 oauthlibの現在のPRは、上記の懸念を満たしていると思います。 include_client_idフラグは、 client_id送信を明示的に許可するかどうかを示します。

requests_oauthlibに関しては、これが私が考えていることです。

1. usernameとpasswordは本文にのみ表示されます（HTTP基本としては表示されません）。 非準拠のサーバー統合にその動作が必要な場合、実装者はauthまたはheaders引数をfetch_token()送信できます。

2. client_idを正しい場所に提供するのは少し面倒ですが、ロジックとユースケースはダウンしていると思います。 これは間違いなくいくつかのレビューが必要になります。

@JonathanHuotと@ibuchananについての質問：

oauthlibのOAuth2 Clientとrequests_oauthlibのOAuth2Sessionは、 client_secretを保持せず、繰り返し呼び出す必要があります。 これはOAuth1には当てはまりませんでしたが、これが＃370の背後にある実際の問題だったと思います。 RFCはこれの必要性について言及しておらず、私は歴史を見つけることができませんでした。

私にとっては、 client_secretを格納してクライアントを拡張し、 fetch_tokenとrequest client_secretを渡すことへのOAuth2Sessionの依存を非推奨にすることは理にかなっています。 requestクライアント自体で現在使用しているものを使用することに賛成。 （これは、https：//github.com/requests/requests-oauthlib/issues/264で報告されている他のいくつかの不整合にも対処します）

ユーザー名/パスワードとclient_id / client_secretのテスト変数を標準化するために、oauthlib（＃593）のPRを少し変更しました。 将来的には、間違いによる両者の混乱を防ぐことができると思います。

リクエストに対して提案された変更-oauthlib： https ：

これはもう少し抜本的です。コードとテストを見ると、ライブラリは、機能してはいけないあらゆる種類のものを機能させようとしていたようです。

修正はいくつかのことを行います：

1. usernameとpasswordチェックは、 LegacyApplicationClientインスタンスでのみ発生します。これが必要な唯一の種類であるためです（正しいですか？）。 チェックの下に、ユーザー名/パスワードをkwargsdictにマージするセクションがあります。 テストでは、他のクライアントがこの情報を渡したい可能性があることが示唆されているため、現在はアウトデントされています。

2. client_id / authヘッダーを処理するためのロジックが書き直され、適切なタイプの認証がデフォルトで適切な場所で行われるようになりました。 ユーザーが別の方法で資格情報を強制したい場合でも、それは可能です。

3. 質問： client_secretが渡されない状況はありますか？ 何も思いつかないのですが、oAuthフローはたくさんあります。

したがって、requests-oauthlibバージョンでは：

| include_client_id | auth | 行動|
| ------------------- | --------------- | -------- |
| なし（デフォルト）| なし（デフォルト）| client_id使用してAuthオブジェクトを作成します。 本文でclient_idを送信しないでください。 RFCが推奨しているため、これはデフォルトの動作です。 |
| なし（デフォルト）| プレゼント| Authオブジェクトを使用します。 include_client_id=False oauthlibのprepare_request_bodyを呼び出す|
| 誤り| プレゼント| Authオブジェクトを使用します。 include_client_id=False oauthlibのprepare_request_bodyを呼び出す|
| 本当| プレゼント| Authオブジェクトを使用します。 include_client_id=True oauthlibのprepare_request_bodyを呼び出す|
| 本当| なし（デフォルト）| client_id使用してAuthオブジェクトを作成します。 include_client_id=True oauthlibのprepare_request_bodyを呼び出す|
| 誤り| なし（デフォルト）| client_id使用してAuthオブジェクトを作成します。 include_client_id=False oauthlibのprepare_request_bodyを呼び出す|

または別の言い方をすると：

• 認証オブジェクトを作成します
  
  
  
  • 本文でクライアントIDを送信しないでください。
  
  
  • （include_client_id = None、auth = None）
  
  
  • （include_client_id = False、auth = None）
  
  
  • 本文でクライアントIDを送信します。
  
  
  • （include_client_id = True、auth = None）
  
  
• 明示的な認証オブジェクトを使用する
  
  
  
  • 本文でclient_idを送信しないでください。
  
  
  • （include_client_id = None、auth = authObject）
  
  
  • （include_client_id = False、auth = authObject）
  
  
  • 本文でclient_idを送信します。
  
  
  • （include_client_id = True、auth = authObject）
  
  

@jvanasco ：oauthlibとrequests-oauthlib側で非常によく見えます。

3.質問について：

client_secretなしで（または空の、RFCの観点からは近い）パブリッククライアントを持つことができます。 したがって、PythonAPIは「秘密なし」をサポートする必要があります。

実際のユースケースは、多くの場合、認証コードを使用することを好むネイティブアプリケーションですが、秘密を安全に保つためのセキュリティを保証することはできません。したがって、 client_secretなしでclient_idを受け入れることもできます。 client_secret （またはRFCと同じ空のclient_secret ）; または、別のPKCE RFCも利用できます（https://oauth.net/2/pkce/を参照）。 しかし、後者はまだoauthlib側では実装されていません。

ありがとう。 client_idなしでclient_secret client_idを送信できることを確認するために、いくつかのテストケースを追加します。 非常に多くの質問をして申し訳ありませんが、この仕様の可能な実装は非常に多くあり

@JonathanHuot既存の実装は、 client_secret空の文字列の送信をサポートしていません。 このロジックでは削除されますhttps://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/parameters.py#L90-L125-具体的には122行目

それをサポートすることは、そのルーチンの直後に次のようなものを追加することです：

if ('client_secret' in kwargs) and ('client_secret' not in params):
    if kwargs['client_secret'] == '':
        params.append((unicode_type('client_secret'), kwargs['client_secret']))

シークレットが空の文字列の場合はclient_secretの空の文字列を送信しますが、値がNone場合はclient_secret送信しません。

RFCが2つのバリアントのいずれかをサポートしている場合、1つのバリアントのみをサポートする多くの壊れた実装が存在する可能性があるため、これをサポートする価値があると思います。

この元の問題はoauthlibで修正されています。 ただし、 https：//github.com/requests/requests-oauthlib/pull/331が修正されるまで、動作はそのままです。