ユーザー/パスなしでRESTful API呼び出しでシステム間のハンドシェイクを保護する方法は？
私の会社の別の部門のシステムXがあり、RESTful APIを使用してシステムに（パスワードではなく）基本的なユーザー情報を送信しています。両方のシステムは同じドメインのサブドメインを使用していますが、異なるサーバー/ネットワーク上にあります。私のシステムへの着信APIリクエストがシステムXからのものとして検証されることを確認したいだけです。
私が遭遇したほとんどすべての記事/質問で、ユーザー資格情報の認証について話をしましたが、要求/応答ごとに資格情報をプッシュしたくないので、これらは私の状況には当てはまりません。
User/pass/oauthなしでこのハンドシェイクを実現するための適切な安全な方法はありますか？
これが私の「頭から離れた答え」です。考えてみると変わる可能性があります。
1）ここで塩に多くのポイントがあるかどうかはわかりません。通常の使用では、ソルトは漏えいしたパスワードデータベースをレインボー攻撃から保護します。それは確かにここでは関係ありません、そしてさらに私は塩の他の理由があるとは思いません。
2）ハッシュによってセキュリティが大幅に向上するわけでもないと思います。ハッシュは、転送中ではなく保管中に秘密を隠すために使用されます。ハッシュしてハッシュを渡すと、ハッシュは効果的にisあなたの秘密であり、盗まれたハッシュは盗まれた秘密よりも危険ではありません。したがって、非常に現実的な意味では、特に定期的に変更されるため、シークレット自体を送信することもできます。
要約すると、効果的に2つの防御策があります。共有シークレット（変更）とIPホワイトリストです。共有シークレットは、主にリプレイ攻撃や盗聴要求などの脆弱性にさらされます。誰かが送信中にそれを見た場合、次の変更までシークレットを知っています。これはシステム間であると述べたので、システムが同じセキュリティゾーンにあるかどうかに応じて、そのようなリクエストがTLS/SSLで発生する必要があるかどうかを判断します。これらのシステムがデータセンター間で通信している場合、おそらくTLS/SSLを介して排他的に通信する必要があります。
セキュリティの2番目のレベルは、IPホワイトリストによるものです。これは主にIPスプーフィングに対して脆弱であり、ネットワークの設定に応じて、問題となる場合とされない場合があります。他にも選択肢はあると思いますが、私はネットワークの専門家ではありません。
まったく異なるアプローチの場合は、ハンドシェイクの実装を試すことができます。基本的な考え方は、サーバーAがサーバーBにリクエストを送信するとき、サーバーBはサーバーAに直接連絡してリクエストを検証し、受け取ったリクエスト全体を渡してYES/NO応答を返すことです（「no」は明らかにサーバーAが問題のリクエストを送信しなかった場合に返されます）。 「YES」を受け取ると、実際にリクエストを処理します。これはセットアップに多くの労力を要し、さらに多くのネットワーク/サーバーリソースを必要とするため、アプリケーションのニーズによっては好ましくない場合があります。利点は、IPスプーフィングを排除し、秘密の交換が不要になることです。ただし、直接的なネットワーク攻撃（MITMなど）を防ぐことはできません。
追加して編集：
握手のアイデアは、実際には私自身のものではありません。私はアプリケーション間でその一般的なフローを使用して、サーバー間の通知を検証しました。私がPaypalから盗んだアイデア自体（それは彼らがIPNを検証する方法です）ですが、それはおそらくもともと彼らのアイデアでもありません。私がこれを指摘しているのは、それが長い間使用されてきた慣行だからです。そのため、ドキュメントを読んでフローを理解し、そのフローが原因で発生した可能性のある過去のセキュリティ問題に関する情報を（可能性として）探すことができます。 。しかしおそらく、Paypalは支払いインフラストラクチャの重要な部分を依存しているため、かなり安全です。
https://developer.Paypal.com/docs/classic/ipn/integration-guide/IPNImplementation/