質問への答えは、コードレベル、プロトコルレベル、またはアーキテクチャレベルになります。プロトコルレベルの問題のほとんどをここで要約しようとします。これは、長所と短所の分析では通常重要だからです。ことを覚えておいてくださいのOAuth2がはるかよりもリソース所有者のパスワードの資格情報、仕様に従って、「レガシーまたは移行の理由」のために存在し、「他の助成金型より高いリスク」とみなされ、仕様が明示的に述べていること、クライアントと認証サーバ「この許可タイプの使用を最小限に抑え、可能な限り他の許可タイプを使用する必要があります」。
基本認証よりもROPCを使用することには多くの利点がありますが、その前に、OAuth2と基本認証の基本的なプロトコルの違いを理解しましょう。これらを説明し、後でROPCに来ますので、ご容赦ください。
ユーザー認証フロー
OAuth2仕様には4つの役割が定義されています。例は次のとおりです。
- リソース所有者：何らかのリソースへのアクセス権を持つユーザー。たとえば、あなたの場合、異なるユーザーはREST APIへの異なるアクセスレベルを持つことができます。
- クライアント：通常、ユーザーが使用しているアプリケーションであり、ユーザーにサービスを提供するためにリソースにアクセスする必要があります。
- リソースサーバー：ケースのREST API。そして
- 承認サーバー：ユーザーの資格情報が提示され、ユーザーを認証するサーバー。
クライアントアプリケーションが実行されると、ユーザーに基づいてリソースへのアクセスが許可されます。ユーザーに管理者権限がある場合、REST APIでユーザーが使用できるリソースと操作は、管理者権限のないユーザーよりもはるかに多くなる可能性があります。
OAuth2では、複数のクライアントで複数のリソースに対して単一の承認サーバーを使用することもできます。例として、リソースサーバーは、Facebookでのユーザーの認証を受け入れることができます（このような場合、承認サーバーとして機能できます）。したがって、ユーザーがアプリケーション（クライアント）を実行すると、ユーザーはFacebookに送信されます。ユーザーはFacebookで資格情報を入力すると、クライアントはリソースサーバーに提示できる「トークン」を取得します。リソースサーバーは、トークンを見て、Facebookが実際にトークンを発行したことを確認して受け入れ、ユーザーがリソースにアクセスできるようにします。この場合、クライアントはユーザーの資格情報（つまり、Facebookの資格情報）を見ることはありません。
ただし、Facebookの代わりにユーザーのIDを管理している（そして承認サーバーを持っている）としましょう。Facebookは既にクライアントにトークンを付与します。ここで、パートナーがいて、そのアプリケーション（クライアント）がREST APIにアクセスできるようにしたいとします。基本認証（またはROPC）を使用すると、ユーザーは認証サーバーに送信するクライアントに資格情報を提供します。認可サーバーは、クライアントがリソースにアクセスするために使用できるトークンを提供します。残念ながら、これはユーザーの資格情報がそのクライアントにも表示されることを意味します。ただし、パートナーのアプリケーション（組織の外部にいる可能性がある）がユーザーのパスワードを知っていることは望ましくありません。これは現在、セキュリティの問題です。その目標を達成するために、
したがって、OAuth2では、理想的にはそのような場合にROPCを使用せず、承認コードフローなどの別のROPCを使用します。これにより、承認サーバーにのみ提示されるユーザーの資格情報をアプリケーションが知ることができなくなります。したがって、ユーザーの資格情報は漏洩しません。基本認証でも同じ問題が当てはまりますが、次のセクションでは、クライアントによる永続的なアクセスのためにユーザーの資格情報をクライアントがROPCに保存する必要がないため、ROPCがどのように優れているかを説明します。
ユーザーが許可サーバーにアクセスするときに、許可サーバーはユーザーに依頼して、クライアントに代わってリソースへのアクセスを許可するかどうかを確認することもできます。そのため、クライアントがリソースにアクセスすることを承認するプロセスがプロセスに含まれるため、承認サーバーと呼ば れます。ユーザーがクライアントを承認しない場合、リソースにアクセスできません。同様に、ユーザー自身がリソースにアクセスできない場合でも、承認サーバーはアクセスを拒否し、トークンを発行できません。
基本認証では、承認サーバーとリソースサーバーも1つのエンティティに結合されます。したがって、リソースサーバーはユーザーを承認するため、クライアントに資格情報を要求します。クライアントは、リソースサーバーがユーザーの認証に使用する資格情報を提供します。これは、複数のリソースサーバーが基本的にユーザーからの資格情報を要求することを意味します。
トークン発行
クライアントは、認可サーバーからトークンを取得し、それらを保持し、それらを使用してリソースにアクセスします（トークン自体の詳細については以下を参照）。クライアントはユーザーのパスワードを（ROPC以外のフローで）決して知らないため、保存する必要はありません。ROPCでは、クライアントがユーザーのパスワードを知っていても、これらのトークンを使用してリソースにアクセスするため、パスワードを保存する必要はありません。対照的に、基本認証では、クライアントがすべてのセッションで資格情報を提供することをユーザーに望まない場合、クライアントは次回に提供できるようにユーザーのパスワードを保存する必要があります。これは、クライアントがWebアプリケーションのみである場合を除き、基本認証を使用することの大きな欠点です。その場合、Cookieはこれらの懸念の一部に対処できます。ネイティブアプリケーションでは、通常、これはオプションではありません。
OAuth2には、トークンがどのように発行され、どのように機能するかに伴うもう1つの側面があります。ユーザーが（ROPCであっても）認証サーバーに資格情報を提供すると、認証サーバーは、1）アクセストークン、および2）更新トークンの2種類のトークンの1つ以上を提供できます。
アクセストークンはリソースサーバーに送信され、リソースサーバーは検証後にリソースへのアクセスを許可します。通常、有効期間は1時間などです。更新トークンは、有効期限が切れたときに別のアクセストークンを取得するために、クライアントによって承認サーバーに送信され、通常は長い有効期間（たとえば、数日から数か月、さらには数年）を持ちます。
クライアントがアクセストークンをリソースサーバーに提供すると、クライアントはトークンを確認し、検証後、トークン内を確認してアクセスを許可するかどうかを決定します。アクセストークンが有効である限り、クライアントはそれを使用し続けることができます。ユーザーがアプリケーションを閉じて翌日に起動し、アクセストークンの有効期限が切れたとします。これで、クライアントは承認サーバーを呼び出し、有効期限が切れていないことを前提に更新トークンを提示します。認可サーバーはすでにトークンを発行しているため、それを検証し、ユーザーが再度資格情報を提供する必要がないことを判断し、クライアントに別のアクセストークンを提供します。これで、クライアントはリソースサーバーに再びアクセスできるようになります。これは通常、FacebookおよびTwitterのクライアントアプリケーションが資格情報を1回要求し、ユーザーが資格情報を再度入力する必要がない方法です。これらのアプリケーションは、ユーザーの資格情報を知る必要はありませんが、ユーザーがアプリケーションを起動するたびにリソースにアクセスできます。
これで、ユーザーは認証サーバーにアクセスして（Facebookユーザープロファイルなどで）、クライアントアプリケーションに影響を与えることなくパスワードを変更できます。それらはすべて正常に機能し続けます。ユーザーが既に更新トークン付きのアプリケーションを持っているデバイスを紛失した場合、承認サーバー（Facebookなど）に既存のアプリケーションを尊重しないことで達成するアプリケーションから「ログアウト」するよう承認サーバー（Facebookなど）に指示できます。トークンを更新し、ユーザーがこれらのアプリケーションを介してリソースにアクセスしようとしたときに、資格情報を再度入力するように強制します。
JWTは、OAuth2およびOpenID Connectで通常使用される単純なトークン形式です。トークンに署名して検証する方法も、すべてのリソースサーバーがさらに別のソリューションを実装する代わりに、利用可能なライブラリで標準化されています。したがって、利点は、吟味され、サポートされ続けているコードの再利用性にあります。
セキュリティへの影響
上記のシナリオのいずれかが図にある場合、基本認証は弱くなります。OAuth2の広範な脅威モデルもあり、その中の提案を使用して実装の一般的な脆弱性を回避できる開発者が利用できます。脅威モデルに目を通すと、実装に関連する多くの脆弱性（オープンリダイレクタやCSRFなど）もカバーされていることがわかります。この応答では、基本認証と比較しませんでした。
OAuth2の最後の主な利点は、プロトコルが標準化され、複数の承認サーバー、クライアント、およびリソースサーバーがそれを尊重することです。開発者は多数のライブラリを利用できます。これらのライブラリは、実装でセキュリティの問題が見つかった場合に維持されるため、相互運用性を確保しながらライブラリが更新されます。
結論
新しいアプリケーションIMOを作成している場合、固有の問題があるため、基本認証とROPCの両方を避けるのが理想的なケースです。ただし、アプリケーションごとにニーズ、タイムライン、開発者の習熟度などが異なるため、決定はケースバイケースです。しかし、基本認証以外の必要性がなくても、選択することで、簡単に拡張できないアーキテクチャに縛られる可能性があります（たとえば、将来複数のサーバーを使用する場合、必ずしも持つ必要はありません）ユーザーは資格情報を各自に提供します。認証サーバーに一度だけ提供するだけで、トークンなどを配布できます）
TLSまたは同様のプロトコル、または所有の証明などを使用して資格情報を保護できるため、資格情報がワイヤ経由で送信される方法についてのあなたのコメントには対処しなかったことに注意してください。それに惑わされます。上記の違いは、通常、アーキテクチャレベルにあります。したがって、アーキテクチャは実装後に変更するのが最も難しいため、ここで焦点を当てています。
私が取り組んでおり、最近公開プレビュー用にリリースされたAzure Active Directory B2C Basicは、サードパーティアプリケーションがAIDをソーシャルIDP（Facebook、Googleなど）との相互運用性を備えた承認サーバーとして使用できるようにします。また、ユーザーはソーシャルIDPを使用する代わりに独自のアカウントを作成でき、それらは後で認証目的に使用できます。他にもいくつかのサービスがあります（たとえば、私が知っている別のサービスは auth0です）開発者はこれを使用して、アプリケーションとリソースの認証とユーザー管理を完全に外部委託できます。上記で説明したのと同じプロトコル特性が開発者によって使用され、承認サーバー（AAD）、リソース（REST APIなど）、クライアント（モバイルアプリケーションなど）、ユーザーを分離します。この説明がいくらか役立つことを願っています。