1

OAuth 1.0A 共有シークレットの利点は何ですか?

私が理解していることから、クライアントは、クライアント ID と共有シークレットの両方を受け取る保護されたリソース サーバーに登録できます。OAuth 1.0A 仕様を何度も読んだことがありますが、次の2 つの質問を理解するのに苦労しています。

  • なぜ共有シークレットが必要なのですか?
  • サーバーがクライアントを検証するのにクライアント識別子が十分でないのはなぜですか? 共有シークレットが提供する追加のセキュリティ上の利点は何ですか?

仕様を引用するためにあなたを探しているわけではありません - 仕様が何を言っているのか理解するのに苦労しているので、この時点でもっと簡単な説明が必要です（とにかく共有秘密の詳細には触れていません） .

4

1 に答える 1

1

シークレットは、リクエストの署名を生成するために必要です。署名がなければ、次の 2 つのことを確認できません。

  1. 第三者がクライアントからのリクエストを傍受し、それを変更してから、まったく別のことを行うためにそれを渡したわけではないこと
  2. 第三者が正当な消費者になりすまして、彼らの関与なしに要求を行っていないこと

プロバイダーとコンシューマーだけがシークレットを知っている場合、署名と検証により、これらの不正な要求が防止されます。この投稿では、署名の背後にある考え方について詳しく説明します。特に、次の抜粋はあなたの質問に非常に関連しています。

ハッシュだけでは、送信者の身元は確認されず、データの整合性のみが確認されます。要求が要求された送信者からのものであることを受信者が確認できるようにするために、ハッシュ アルゴリズムが共有シークレットと組み合わされます。双方が自分だけが知っている共有秘密に同意する場合、ハッシュされるコンテンツにそれを追加できます。これは、単にシークレットをコンテンツに追加するか、HMAC などのシークレットのメカニズムが組み込まれたより洗練されたアルゴリズムを使用することで実行できます。どちらの方法でも、署名の生成と検証には共有シークレットへのアクセスが必要です。これにより、攻撃者がリクエストを偽造または変更することを防止できます。

于 2014-11-07T22:41:42.443 に答える