AWS署名V4とOAuth + JWTベアラートークン
REST APIを保護するために、アクセス制御の論理的な選択は、単独で、またはOAuthと組み合わせてJWTです。呼び出し元の認証のみに関心がある場合は、JWT署名の検証だけで十分です。私は認証も気にかけており、OAuthなどのトークンサービスも使用します。どちらの方法でも、HTTPリクエストにAuthorization: Bearer [JWT token]のようなヘッダーを含めます。
AWSには、リクエスト自体の一部に署名し、Authorization: AWS4-HMAC-SHA256 ....のようなヘッダーを含めるAPIアクセス制御用の 独自の標準 があります
私の質問：
aWSアプローチはリプレイ攻撃に対してより安全ですか？トークンの有効期限が短い場合でも、仮にベアラートークンを別のリクエストで再利用することは依然として可能であるためです。署名は、リクエストが改ざんされていないことを意味します。
より安全な場合、OAuthやJWTのような業界標準と見なす必要がありますか？標準のアプリフレームワークは、検証側でどの程度サポートを提供しますか？.
aWSアプローチはリプレイ攻撃に対してより安全ですか？トークンの有効期限が短い場合でも、仮にベアラートークンを別のリクエストで再利用することは依然として可能であるためです。署名は、リクエストが改ざんされていないことを意味します。
はい、リプレイ攻撃に対してより安全です。あなたが提案したように、ベアラートークンはあらゆるリクエストで使用できます（理論的にだけではありません）。それらは、許可するリクエストとは完全に独立しています。一方、AWS署名は、関連付けられているリクエストに「バインド」されています。署名されたリクエストには、特定のウィンドウ内にあることを確認するためにAWSによってチェックされるタイムスタンプも含まれています。リクエストはこのウィンドウでのみ再生できます。
あなたが言ったように、署名はリクエストの完全性を保証します。整合性はHTTPSによっても提供されます。 AWSスキームは、HTTPSが削除された場合でも整合性を維持します。
より安全な場合、OAuthやJWTのような業界標準と見なす必要がありますか？標準のアプリフレームワークは、検証側でどの程度サポートを提供しますか？.
より多くのセキュリティプロパティを提供します。 AWSの動作を複製しようとする他のHTTP署名スキームがいくつかあります。 これはドラフトです 。 Joyentは 自身のスキーム も作成しました。 AWSスキームを完全に複製する Escher と呼ばれるライブラリもあります。また、互換性があり、検証側も含まれています。
免責事項：私はエッシャーを開発した会社で働いています。多くのサービスを接続するために本番環境で使用します。
aWSアプローチはリプレイ攻撃に対してより安全ですか？トークンの有効期限が短い場合でも、仮にベアラートークンを別のリクエストで再利用することは依然として可能であるためです。署名は、リクエストが改ざんされていないことを意味します。
APIを使用して送信されるすべてのリクエストには、タイムスタンプが関連付けられています。 AWSは、タイムスタンプ後5分を超えて受信されたリクエストを拒否します。 5分以内の再生では、キャッシュされた要求のスライディングウィンドウを維持するだけで済みます。ハッシュをキャッシュ内のハッシュと照合し、リプレイを検出できます。
より安全な場合、OAuthやJWTのような業界標準と見なす必要がありますか？標準のアプリフレームワークは、検証側でどの程度サポートを提供しますか？.
リクエストをハッシュし、リクエストとともにハッシュを送信するという基本的な概念について話している場合、それはすでに行われていることです。 Amazonがここで使用しているシステムは、リプレイ攻撃を検出する同様のメカニズムを備えたKerberosシステムと、リクエストをハッシュして添付し、途中で改ざんされないようにするというアイデアに触発されたように感じます。