[解決済み】OAuth 2は、Security Tokenを使用したリプレイ攻撃などからどのように保護するのでしょうか？

質問

私の理解では、OAuth 2では、次のような一連のイベントが発生します。 Site-A にアクセスする。 ユーザーの の情報を Site-B .

1. Site-A に登録されます。 Site-B で、SecretとIDを取得します。
2. いつ ユーザー が伝える Site-A にアクセスする。 Site-B , ユーザー に送信されます。 Site-B と伝えると Site-B を贈りたいということです。 Site-A を特定の情報に対して許可しています。
3. Site-B リダイレクト ユーザー に戻る Site-A と、認証コード。
4. Site-A は、その認証コードとそのシークレットを Site-B セキュリティ・トークンと引き換えに
5. Site-A にリクエストを行い Site-B に代わって ユーザー リクエストと一緒にセキュリティトークンをバンドルすることによって。

セキュリティと暗号化という点では、高いレベルでどのように機能するのでしょうか？OAuth 2 は、Security Token を使用したリプレイ攻撃などからどのように保護するのでしょうか？

解決するには？

読んだ内容からすると、こういうことですね。

質問で説明した大まかな流れは正しいです。ステップ2では、ユーザーXが認証され、サイトBにあるユーザーXの情報へのサイトAのアクセスを承認します。ステップ4では、サイトがサイトBにシークレットを返し、自身を認証するとともに、要求しているもの（ユーザーXのアクセストークン）を示す認証コードも渡します。

全体として、OAuth 2 は実際には非常にシンプルなセキュリティモデルであり、暗号化が直接的に作用することはありません。その代わり、シークレットとセキュリティトークンは本質的にパスワードであり、全体はhttps接続のセキュリティによってのみ保護されています。

OAuth 2は、Security TokenやSecretのリプレイ攻撃に対する防御を持ちません。その代わり、サイトBがこれらのアイテムに責任を持ち、外部に漏らさないことと、転送中にhttpsで送信されることに完全に依存しています（httpsはURLパラメータを保護します）。

認証コードステップの目的は単に利便性であり、認証コードはそれ自体では特に機密性が高いものではありません。サイトBにユーザーXのアクセストークンを要求する際に、サイトAに対するユーザーXのアクセストークンの共通識別子を提供するものです。サイトBのユーザーXのユーザーIDだけではうまくいきません。なぜなら、異なるサイトに同時に配布されるのを待っている未処理のアクセストークンが多数存在する可能性があるからです。