OAuth 2にResource Owner Password Credentials Grantがあるのはなぜですか？

Question

誰もこの種の助成金でOAuth 2を使用しますか？つまり、クライアントがすでにリソース所有者の名前とパスワードを持っている場合、リソースサーバーが使用する認証媒体を使用してリソース所有者として認証するだけではどうですか？

私はここでその根拠を理解していません。誰か説明できますか？

Answer 1

仕様は述べているように、リソース所有者のパスワードの資格情報の助成金は、移行の目的のためであり、唯一のクライアントと認証サーバは、同じパーティで制御されている（通常は）シナリオの、https://tools.ietf.org/html/rfc6749#section-1.3.3での適用：

リソース所有者のパスワード資格情報（ユーザー名とパスワード） は、アクセス権を取得するための認可資格として直接使用することができます
トークン。リソースの所有者とクライアント間の信頼関係（例えば、
クライアントは、デバイスのオペレーティングシステムまたは高い特権
アプリケーションの一部である）、そしてときに、他の認可の高い
度があるときに資格情報にのみ使用してください許可タイプは
ではありません（認証コードなど）。

これは、クライアントと認証の間でトークンを取得する「に-廃止される」方法を使用しながら、クライアントとリソースサーバーの間の脚上の標準的なトークンおよびプロトコル（例えばOAuth 2.0のベアラトークン）を利用することができますサーバ。 https://tools.ietf.org/html/rfc6749#section-10.7：

リソースオーナーパスワードクレデンシャルはタイプがしばしば
レガシーまたは移行の理由のために使用されて付与します。これにより、クライアントによる
のユーザー名とパスワードの格納の全体的なリスクは軽減されますが、高い特権の資格情報をクライアントに公開するためには、 の必要性が排除されません。

この認可タイプは、このプロトコルが回避するパスワードのパターンを維持しているので、他の認可タイプ より高いリスクを持ちます。 を回避してください。クライアントはパスワードを濫用する可能性があります。または、パスワード が意図せずに攻撃者に漏洩する可能性があります（たとえば、クライアントが保管しているログファイル など）。リソースの所有者が（それはクライアントにその資格情報を引き渡す際 リソースの所有者の関与が終了する）承認プロセス を制御できませんので、クライアントがより広い範囲で
アクセストークンを取得することができますさらに

、リソースによって希望される。
所有者。認可サーバーは、この認可タイプによって発行されたアクセストークンの有効期間と
を考慮する必要があります。

許可サーバーとクライアントは、この 許可タイプの使用を最小限に抑え、可能な限り、他の許可タイプを利用するべきです（SHOULD）。

Answer 2

私は別の観点を提供する。

OAuth 2.0は、一般的なWebアプリケーション用の優れたプロトコルです。しかし、一部のアプリケーションでは、より強力な認証/認証メカニズムが使用されます。これらの場合、強力な方法を使用してトークンの確立を許可するのが理にかなっています。このようなアプリケーションの例としては、銀行API（これは銀行のウェブサイトを使用したウェブ上での古典的なOAuth 2.0フローと、ネイティブモバイルやデスクトップアプリケーション向けのPowerAuth 2.0などのプロトコルを使用した強力なデータ署名を使用できます）