最初のケースでは、通信ごとに要求を識別する HMAC を生成する必要があるため、サーバーはそれを再生成して、クライアントが承認されていることを確認できます (HMAC は、サーバーのみが知っている秘密鍵で暗号化されており、一方、2 番目のサービスでは、サービスが証明書 (またはトークン) を 1 回発行するだけで済み、それを数分間維持する必要があります。15分-。もちろん、MITM 攻撃やリプレイ攻撃を防ぐには、すべての結果 (より多くの帯域幅とより多くの CPU 要件) を備えた SSL 経由でのみ送信する必要があります。
個人的には、1 番目はより単純であるだけでなく、より強力であることがわかりました。これは、各リクエストが独自のデータを持っているためです。2 番目は SSL 証明書の整合性に依存しています (署名された SSL 証明書を簡単にクラックできると言っているわけではありませんが、誰かがすべての通信ですべてのトラフィックが傍受される可能性があります)。
したがって、次の長所/短所があることがわかりました。
- HMAC の長所: リクエストごとに一意のトークン。一意のデータを使用して署名とタイムスタンプを構成することにより、MITM およびリプレイ攻撃に対して非常に安全です。実装が簡単です。
- HMAC の短所: トークンを再生成するために、単一のリクエストごとにサーバーが動作する必要があります。
- トークン プロ: 複数のリクエストに対して 1 つのトークン。複数のクライアント アクションを必要とするサービスで役立ちます。
- トークンの短所: すべての通信に SSL が必要です。
最終的な答えを得るにはいくつかのテストを設定する必要があると思いますが、誰かがすでにある程度の知識や過去の経験に基づいた考えを持っているかどうかを知りたい.