OAuth 2は、セキュリティトークンを使用したリプレイ攻撃などからどのように保護しますか？

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

1. Site-Aに登録しSite-B、シークレットと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は、セキュリティトークンを使用したリプレイ攻撃などからどのように保護しますか？

OAuth 2.0が実際にどのように機能するか：

仕事に行く途中、オラフのベーカリーを運転していたとき、窓の中で最もおいしいドーナツが見えた。それで私は中に入って、「私はそのドーナツを持っていなければならない！」と要求しました。彼は「確かにそれは30ドルになるだろう」と言った。

ええ、知っています。ドーナツ1つにつき30ドルです。美味しい！突然、「いや、あなたにはドーナツがない」というシェフの叫び声が聞こえてきました。私は尋ねました：なぜですか？彼は銀行振込のみを受け入れると述べた。

マジ？うん、彼は真面目だった。すぐそこへ歩いて行ったところ、ドーナツが「食べて、美味しい…」と声をかけました。ドーナツからの注文に反対するのは誰ですか？私はオーケーと言った。

彼は自分の名前が書かれたメモ（ドーナツではなくシェフ）を私に渡しました：「オラフがあなたに送ったことを教えて」彼の名前はすでに記されていたので、それが何を言っているのかはわかりませんが、わかりました。

私は私の銀行に1時間半運転しました。紙幣を窓口に渡しました。私は彼女のオラフが私を送ったと言った。彼女は私にそれらのルックスの1つを与えました。

彼女は私のメモを取り、私のIDを尋ね、彼に与えるのにどれだけのお金が大丈夫か尋ねました。私は彼女に30ドルと伝えました。彼女は落書きをして私に別のメモを渡した。これにはたくさんの数字がありました、それが彼らがノートを追跡する方法だと思いました。

その時点で私は飢えています。私はそこから急いで出て、1時間半後に私は戻って、メモを伸ばしてオラフの前に立っていました。彼はそれを取り、それを見て、「私は戻ってきます」と言った。

私は彼が私のドーナツを手に入れていると思いました、しかし、30分後に私は疑わしくなり始めました。それで、カウンターの後ろの人に「オラフはどこ？」と尋ねました。彼は「彼はお金を得るために行きました」と言った。"どういう意味ですか？"。「彼は銀行にメモを取る」。

ええと...オラフは銀行が私に与えたメモを取り、銀行に戻って私の口座からお金を引き出しました。彼は銀行が私に与えたメモを持っていたので、銀行は彼が私が話している男だと知っていました、そして私が銀行と話したので彼らは彼に30ドルだけを与えることを知っていました。

私がそれを見上げるまでに、オラフは私の目の前に立っていて、ついにドーナツを手渡してくれたので、それを理解するには長い時間がかかったに違いありません。私が去る前に、「オラフ、いつもこの方法でドーナツを売っていましたか？」と尋ねなければなりませんでした。「いいえ、以前は別の方法でやっていました。」

ええと。車に戻ると、電話が鳴った。私はわざわざ答えなかった、それはおそらく私を解雇するようにという私の仕事でした、私の上司はそのような***です。その上、私がたった今行ったプロセスについて考えていた。

考えてみてください。オラフに口座情報を提供する必要なく、銀行口座から30ドルを引き出すことができました。そして、私はすでに銀行に30ドルしか取ることが許されないことを銀行に言ったので、彼があまりにも多くのお金を取り出すことを心配する必要はありませんでした。そして銀行は彼が私にオラフに与えるために与えたメモを持っていたので彼が正しい人であることを知っていました。

はい、ポケットから$ 30を渡したほうがいいでしょう。しかし、彼はそのメモを持っているので、私は銀行に彼に毎週30ドルをとるように言うことができ、それから私はパン屋に現れるだけでよく、もう銀行に行く必要はありませんでした。電話でドーナツを注文することもできます。

もちろん、私はそんなことは決してしません-そのドーナツは嫌なものでした。

このアプローチにはもっと幅広いアプリケーションがあるのだろうか。彼はこれが彼の2番目のアプローチであると述べました。私はそれをOlaf 2.0と呼ぶことができます。とにかく家に帰ったほうがいいです。新しい仕事を探し始めます。しかし、街のあちこちにある新しい場所からいちごのシェイクを手に入れる前に、そのドーナツの味を洗い流すために何かが必要です。

私が読んだことに基づいて、これはすべてがどのように機能するかです：

質問で概説されている一般的なフローは正しいです。ステップ2で、ユーザーXが認証され、サイトAがサイトBのユーザーXの情報にアクセスすることも許可します。ステップ4で、サイトはそのシークレットをサイトBに戻し、自身を認証し、認証コードを示します。 （ユーザーXのアクセストークン）が必要です。

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

OAuth 2には、セキュリティトークンまたはシークレットのリプレイ攻撃に対する保護機能がありません。代わりに、サイトBがこれらのアイテムに責任を持ち、それらを外に出さないこと、および転送中にhttps経由で送信されることに完全に依存しています（httpsはURLパラメーターを保護します）。

Authorization Codeステップの目的は単に便宜上のものであり、Authorization Code自体は特に重要ではありません。これは、サイトBにユーザーXのアクセストークンを要求するときに、サイトAのユーザーXのアクセストークンに共通の識別子を提供します。サイトB上のユーザーXのユーザーIDだけでは機能しませんでした。これは、同時に別のサイトに配布されるのを待っている未処理のアクセストークンが多数存在する可能性があるためです。

OAuthは、サードパーティのアプリが別のウェブサイトに保存されているデータに、アカウントとパスワードなしでアクセスできるプロトコルです。より公式の定義については、Wikiまたは仕様を参照してください。

以下にユースケースのデモを示します。

1. LinkedInにログインして、Gmailの連絡先に含まれている友達を接続したいと考えています。LinkedInはこれをサポートしています。gmailから安全なリソース（私のGmail連絡先リスト）を要求します。だから私はこのボタンをクリックします：
   

2. アカウントとパスワードを入力すると、Webページがポップアップし、Gmailのログインページが表示されます。
   

3. 次に、Gmailで[同意する]をクリックする同意ページが表示されます。

4. LinkedInがGmailの連絡先にアクセスできるようになりました。

以下は、上記の例のフローチャートです。

ステップ1：LinkedInはGmailの承認サーバーにトークンを要求します。

ステップ2：Gmail承認サーバーがリソースの所有者を認証し、ユーザーに同意ページを表示します。（ユーザーがまだログインしていない場合、ユーザーはGmailにログインする必要があります）

ステップ3：ユーザーがLinkedInにGmailデータへのアクセスをリクエストすることを許可します。

ステップ4：Gmail認証サーバーがアクセストークンで応答します。

ステップ5：LinkedInはこのアクセストークンでGmail APIを呼び出します。

ステップ6：アクセストークンが有効な場合、Gmailリソースサーバーは連絡先を返します。（トークンはGmailリソースサーバーによって確認されます）

OAuthの詳細については、こちらをご覧ください。

図1、RFC6750から抜粋：

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

これがOauth 2.0の仕組みです。この記事で詳しく説明しています

これは宝石です：

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

非常に簡単な要約：

OAuthは4つの役割を定義します。

1. リソース所有者
2. クライアント
3. リソースサーバー
4. 認可サーバー

あなた（リソース所有者）は携帯電話を持っています。複数の異なるメールアカウントがありますが、1つのアプリにすべてのメールアカウントが必要なため、切り替えを続ける必要はありません。したがって、GMail（クライアント）は、Yahooメール（リソースサーバー）へのアクセスを（Yahooの承認サーバー経由で）要求するので、GMailアプリケーションで両方のメールを読むことができます。

OAuthが存在する理由は、GMailがYahooのユーザー名とパスワードを保存することが安全でないためです。

他の答えは非常に詳細であり、OPによって提起された質問の大部分に対処します。

詳しく説明し、具体的にはOPの「OAuth 2はセキュリティトークンを使用したリプレイ攻撃などからどのように保護するのですか？」という質問に対処するため、OAuth 2の実装に関する公式の推奨事項には2つの追加の保護があります。

1）トークンには通常、短い有効期限があります（http://tools.ietf.org/html/rfc6819#section-5.1.5.3）：

トークンの短い有効期限は、次の脅威に対する保護の手段です。

• 再生...

2）トークンがサイトAで使用される場合、URLパラメーターとしてではなく、承認リクエストヘッダーフィールド（http://tools.ietf.org/html/rfc6750）で提示することが推奨されます。

クライアントは、「ベアラ」HTTP認可スキームで「認可」リクエストヘッダーフィールドを使用して、ベアラトークンで認証済みリクエストを作成する必要があります。...

「application / x-www-form-urlencoded」メソッドは、参加しているブラウザが「Authorization」リクエストヘッダーフィールドにアクセスできないアプリケーションコンテキスト以外では使用しないでください。...

URIクエリパラメータ...は現在の使用を文書化するために含まれています。セキュリティの欠陥のため、その使用は推奨されません

これはおそらく、4つの許可タイプすべて、つまりアプリがアクセストークンを取得できる4つの異なるフローでOAuth2がどのように機能するかを最も簡単に説明したものです。

類似点

すべての付与タイプのフローには2つの部分があります。

• アクセストークンを取得
• アクセストークンを使用

2番目の部分「アクセストークンの使用」はすべてのフローで同じです

差

各付与タイプのフロー「アクセストークン取得」の最初の部分は異なります。

ただし、一般に、「アクセストークンの取得」の部分は5つのステップで構成されます。

1. アプリ（クライアント）をOAuthプロバイダー（Twitterなど）に事前登録して、クライアントID /シークレットを取得します
2. クリックしたユーザーが認証を受けるためにOAuthプロバイダーにリダイレクトされるように、ページにクライアントIDと必要なスコープ/権限を含むソーシャルログインボタンを作成します
3. OAuthプロバイダーは、アプリ（クライアント）に権限を付与するようユーザーに要求します
4. OAuthプロバイダーはコードを発行します
5. アプリ（クライアント）がアクセストークンを取得する

以下は、5つのステップに基づいて各付与タイプのフローがどのように異なるかを比較した並べた図です。

この図はhttps://blog.oauth.io/introduction-oauth2-flow-diagrams/からのものです

それぞれ、実装の難しさ、セキュリティ、およびユースケースのレベルが異なります。ニーズと状況に応じて、それらのいずれかを使用する必要があります。どちらを使用しますか？

クライアント資格情報：アプリが1人のユーザーのみにサービスを提供している場合

リソース所有者のパスワード資格情報：これは、ユーザーが自分の資格情報をアプリに渡す必要がある最後の手段としてのみ使用する必要があります。つまり、アプリはユーザーができるすべてのことを実行できます

認証コード：ユーザー認証を取得する最良の方法

暗黙：アプリがモバイルアプリまたはシングルページアプリの場合

選択の詳細については、こちらをご覧ください：https : //blog.oauth.io/choose-oauth2-flow-grant-types-for-app/