OAuth 2.02本足認証とSSL / TLS
安全な方法で通信する必要がある2つのエンタープライズサーバーがあり、SSLを使用して（両側を検証するクライアント/サーバー証明書を使用）とOAuth 2.0を使用して）を使用した2本足の認証を比較しています（オプションでMACトークンまたはJWTトークン）。
歴史的にOAuthはまったく異なる目的で作成されたようです（ユーザーがサービスにどこかでデータへのアクセスを許可している3本足の場合）、そして2本足は現在OAuth 2.0仕様、私が見た2本足のOAuth 2.0は、SSLを介した追加の保護をあまり提供していないようです。
私が考えることができる唯一のポイントは、OAuthはSSLよりも構成が簡単である可能性があり、セキュリティを危険にさらす可能性のある不正なSSL証明書を受け入れるなどの間違いを犯しやすいということです。しかし私はそうではありませんこれがOAuthを使用するのに十分な理由であるかどうかを確認してください。
これらを個別のオプションとして言及していることに注意してください。ただし、OAuthを使用すると、HTTPS/SSLの上で使用する必要があるため、両方が使用されると思います。
サーバー間通信にOAuth 2.0 2本足スキーム）を使用することの本当の利点はありますか（ユーザーは関与しません）？
注：似たような投稿を見つけました ここ ですが、それはかなり古いものですが、この問題について満足のいく答えが得られたとは思いません。
私はこのコメントに返信します：
私の質問は、各マシンを識別するために適切なクライアント/サーバー証明書でSSLを使用していると仮定すると、サーバーを承認するためにその上にOAuth（2レッグまたは類似）を使用する値は何ですか？お互いに（ユーザーが関与していないと仮定します）ありがとう– Locksleyu
要約：私は両方を気にしないでしょう。
詳細：2本足OAUTHは、コンシューマーシークレットと同じくらい安全です。同様に、相互認証SSLは、秘密鍵と同じくらい安全です。これらを暗号化されたものに保存すると思います。両方が同じ場所に保存されているため、OAUTHを追加してもセキュリティが強化されることはありません。
相互認証SSLと認証付きの標準SSLのどちらを選択するかを検討している場合は、おそらくOAUTHがその役割を果たすことができます。これらのオプションのどちらかが簡単だと思います。したがって、 OAUTHシステムが設置されており、サーバー認証を簡単に追加できます。おそらくそれが方法です。それ以外の場合は、相互認証SSLを使用してください。構成するのは少し面倒ですが、一度設定すると、うまく機能します。
あなたがすでにこれを知っているが、あなたの投稿でそれが明確でないならば、謝罪します。
OAuthとSSL\TLSは、OSIモデルの2つの別個のレイヤーです。 OAuthは認証用で、レイヤー7の最上位にあり、SSL\TLSはレイヤー4のトランスポートセキュリティ用です。SSLとクライアント証明書はどちらもPKIを使用しているため、混同しがちです。
あなたはOAuthの理解が正しいです...それは組織\サーバーではなく個人を承認するために使用されます。 2本足のOAuthは、さまざまな代替のOAuthフローを含む、一般的な用語です。これらはすべて標準に準拠していません。
私の意見では、サーバーとサーバー間の通信を保護するためにクライアント証明書を使用したいと考えています...本当に必要なのは、SSL（トランスポートセキュリティ）とクライアント証明書（認証）の両方として使用できる単一のx509証明書だけです。 2つの証明書を使用するのが一般的ですが。
あなたの質問に答えるために、「サーバーを相互に承認するために、その上にOAuth（2レッグまたは類似）を使用すると、どのような値が使用されますか（ユーザーが関与していないと仮定）」
以下を参照してください
https://salesforce.stackexchange.com/questions/93887/mutual-authentication-two-way-ssl-oauth