プロキシを使用して、パスワード付与呼び出しでOAuthクライアント資格情報を非表示にするのはなぜですか？
2014年11月の記事 Alex BilbieによるOAuthユーザーは、クライアントに資格情報を送信させないようにアドバイスされました（client_idおよびclient_secret）Resource Owner Passwordgrant呼び出しを実行するとき。私が理解している考え方は、クライアントがその資格情報をリクエストに追加できるようにするには、それらの資格情報をソースコード（多くの場合HTML/JS）で記述し、潜在的な攻撃者がアクセスできるようにする必要があります。クライアントを偽装するAPIの呼び出しを実行します。
別のブログ投稿のコメント で、作者は以下を追加しました：
ソースを表示してクライアントの認証情報をコピーできれば、OAuthサービスに対して認証してAPIを呼び出すことができる独自のアプリを作成するのに何の問題もありません。
提案された回避策は、クライアントがAPIを直接呼び出すのではなく、代わりにクライアントクレデンシャルを要求に追加し、それをAPIに転送する役割を担うシンプロキシを呼び出すことです。
素朴なOAuth=初心者なので、これがなぜ攻撃者が私のAPIを呼び出さないようにするのか理解できません。クライアントがその資格情報をリクエストに追加する必要がない場合、誰も行いません。プロキシーが自動的に資格情報を追加するため、APIに送信された要求は、許可されたクライアントからの要求として処理されます。
誰かがTwitterでAlex Bilbieに質問しました まさにこの質問 。これが彼の答えです：
プロキシをどのように保護しますか？攻撃者はプロキシにリクエストを送信し、シークレットを喜んで記入することはできないのですか？
ポイントは、バックエンドの実装の詳細を隠しているため、より多くの制御を保持しているということです
実装の詳細を非表示にすることで（セキュリティ面で）何を得ることができるかを確認できず、同時にクライアントが自身を認証する必要をなくすため、誰かがこの回答について詳しく説明してくれるとありがたいです。
リンクされたブログ投稿を読んだ後、 OAuth 2.0 RFC で彼の問題を相互参照した後、私は彼の懸念に関していくつかの問題を抱えています。彼のブログ投稿の最初のセクションでは、Resource Owner Password Credentials Grantを使用したシングルページWebアプリケーション内でのOAuthの使用に関して、2つの大きな問題があります。
client_idとclient_secretはJavascriptに組み込まれています。- 攻撃者はJavaScriptから
access_tokenおよびrefresh_tokenにアクセスすることもできます。
最初の問題に対処するには、RFCの セクション4.3.2 にResource Owner Password Credentials Grantフローを使用してaccess_tokenを要求するための要件を示します。プロバイダーはクライアントを信頼するため、これらの要件にはclient_secretは含まれていません。このフローが信頼できないクライアントに使用された場合、クライアントはユーザーusernameとpasswordを使用してプロバイダーに対して認証するだけなので、client_secretは必要ありません。このフローは基本的に、従来のパスワードベースの認証スキームを複製します。
2番目の問題は存在しますが、著者は実際にはその影響を説明していません。ユーザーのaccess_tokenにアクセスするには、攻撃者はユーザーのコンピューターに物理的にアクセスするか、Web内のクロスサイトスクリプティングのような別の脆弱性を悪用する必要があります。 access_tokenは、secureおよびhttp-only Cookieフラグなどの組み込みメカニズムがaccess_tokenを保護するために組み込まれていないことを除いて、基本的にセッションCookieと同等です。
これは、アプリケーションがWebアプリケーションが通常は公開しない秘密データを公開してはならないため、シンプロキシを介してAPIリクエストを送信する正当な理由がないことを意味します。