SSLを使用したサーバー間通信で、基本認証の代わりにOauth2を使用するのはなぜですか？
一部のAPIプロバイダーが、HTTPS経由でのみ利用可能なサーバー間通信でOauth2を実装するように要求するのはなぜですか？
フロントエンド（アプリまたはウェブアプリ）では、Oauth2は、ローカルストレージ、ファイルシステム、またはCookieに資格情報ではなくトークンを格納することでユーザー資格情報を保護するのに役立ちます。httpsチャネルがない場合、資格情報を渡すことはお勧めできません。取り消される、または最終的に期限切れになるトークンではなく、各呼び出し。
しかし、なぜoauth2サーバー側の実装プロセスを経て別のサーバーと通信するのでしょうか。資格情報はサーバーに保存されます。違反が発生した場合、トークンが悪用されているかどうかにかかわらず、SSLチャネルは中間者やリプレイ攻撃から保護します。このシステムは、Basic Authの代わりにouth2を使用するとどのように安全になりますか？
このトピックについて同様の質問がありますが、具体的な回答はありません。そのため、もう一度トピックを取り上げようとしています サーバー間通信でのOauth2とAPIKey
認証に「ユーザー名+パスワード」を使用する場合、意図的に遅い安全なパスワード保存方法を使用してパスワードが保存されるため、パスワードの認証に時間がかかるため、リクエストごとにパスワードを送信することが問題になります。したがって、パスワードを1回使用して、長いコンピューター生成トークンを取得し、それを後続のリクエストで送信します。
高エントロピー（長い、コンピューター生成）トークンは、RAMのみに保存するか、データベースに1回だけハッシュして保存できるため、リクエストごとに検証するのは簡単です。
ステートレスにすることもできます（たとえば、ユーザーIDとタイムスタンプのHMAC、サーバーでのみ利用可能なキーを使用）。無効化では、有効なトークンのホワイトリストではなく、無効化されたトークンのブラックリストを保存する必要があります。ブラックリストは、有効期限が切れるにつれて縮小します。
すべてのリクエストで人間が生成したパスワードを送信する場合（素朴な基本認証）-停止します。すべてのリクエストで長いコンピューター生成トークンを送信する場合、HTTPリクエストでそれをどのようにフォーマットするかは重要ではありません。通常のAuthorizationヘッダーを使用する利点は、既存のコードの多くがすでにログに記録しないことがわかっていることです。トークンを_Authorization: bearer <40char>_としてフォーマットしても、Authorization: basic base64(user_id:token or just first-half-of-token:second-half-of-token)としてフォーマットしても、それは重要ではありません。
完全なOAuth2は、必要でない場合はコードが多すぎるため（悪いセキュリティバグが含まれる可能性があります）、単純なもの（単純な方が良い）を使用できます。ただし、少なくともリクエストあたりのコストと無効化の仕組みを考慮する必要があります。
正解です。実際のセキュリティ上のメリットはありません。 HTTPSが必須の場合、基本認証は安全です。ほとんどの場合、それは単なる好みであり、APIを実装した人は、複数の認証スキームではなくOauth2のみに依存することを決定しました。設計の決定はプロジェクトごとに大きく異なる可能性があり、その状況を知らずに判断することは困難です。