Oauth2サーブレットを使用してFacebookアカウントとGoogleアカウントを正常に認証できました。私はタイマーとセッションクッキーを使ってstateを使って、それが正当なOauthコールバックであることを確認しようとしています。私も、私は、プロバイダのOAuthページからリダイレクトされたことを確実にするためにHTTP Refererヘッダを調べる場合OAuth 2コールバックでHTTP Refererを確認する必要がありますか？
どんな利点がありますか？
利点がない場合は、HTTP Refererフィールドも調べても問題はありますか？
答えは次のとおりです。
No, you shouldn't use it, and there is NO valuable benefit of doing it.
認可サーバも、この非常に認識しています。そしてhereが述べられました。
コールバックURLのページがすぐにURLに認証コードを受け取った後、信頼できるページにリダイレクトする必要があります。これにより、ブラウザの履歴に認証コードが残らないようにするか、誤ってリファラーヘッダにリークするのを防ぐことができます。
あなたはCSRFを心配している場合は、パラメータ状態は、あなたがしているどの音（ある理由です、承認の起源を確認するための手法として、HTTPリファラーを使用しません。を使用して）。
oauth2プロトコルのセキュリティ上の懸念がある場合は、full section inside the draftがあります。
他のセキュリティに関する考慮事項がある場合は、this is the sourceです。 状態：
私はあなたのparamの周りのすべての検証を実装するすべてのあなたの努力を与える示唆しています。
編集：
質問、you are really answeredあなた自身の質問のニュアンスを読んだ後。両方のケースでクッキー（おそらくHTML5ローカルストレージ）を使用することは、これまでに知っている最良の解決策です。
最初のニュアンスはCSRFについてですと利用できる可能性対策の一つはChecking the HTTP Referer headerであり、これはすでにaddressed in the protocolました。
第2のニュアンスは完全にはわかりませんが、エクステンショングラントのケースではありますが、これはSAML oauth2 extensionと同じ「認証プロキシリクエスタ」として働く可能性があるためです。
ねえ、すばらしい答えをありがとう。私自身の答えを見て、おそらくあなたの答えを私のものに関連付けることができますか？私は、セッション固定（とおそらく他のユーザー）という用語を認識していません。私はちょっとあなたが私自身の答えにある問題に取り組んでいると感じているので、ちょっとした説明を追加できたらあなたの答えを受け入れたいと思います。ありがとう！ :) – necromancer
私はすぐに期限が切れるので、賞金を授与しています。私はあなたも答えを編集する（おそらく私とマージ）ので、私もそれを受け入れることができます願っています。ありがとう！ – necromancer
HTTPリファラーを確認しないでください。あなたが使用していると思う「状態」パラメータは、クロスサイトリクエストフォージェリ（CSRF）攻撃に対して防御するためにapproach OAuth 2.0 definesです。
新しいO'Reillyの本Getting Started with OAuth 2.0をRyan Boydが見てみたいです。これは、これと関連するセキュリティの考慮事項について説明します。
はい、私は非常に堅牢なチェックのために状態を使用しています。 RFCにリンクしてくれてありがとうございます（しかし、私のエンジニアは、Oauthの書籍に認証のためだけにOauthを使用するのと同じように簡単に言及することに怒りを感じています） – necromancer
謝罪;私は怒らせるつもりはなかった！正直言って私はその本が本当に貴重なものだと私は推薦した主な理由を見つけました。 =）（これは新しいものなので広く知られていない）私はそれとは関係がない。ちょうど良い読書。 – Will
ああ、謝罪しないでください！私は単にユーモラスであった;）貴重な本を見つけてうれしく思います。複雑なクライアント、サーバーとブラウザの通信ワークフロー、デバイスやアプリケーションはもちろんのこと、非常に重要な情報を持っていると確信しています。表紙の細かい動物で、環境にやさしい本です。 （これを読むために、あなたはあなたの最初のupvoteを得る;） – necromancer
号
私は、悪意のある攻撃者として私が好きなヘッダをシミュレートすることができます。私はそれがhttp://cia.fbi.gov.vpn/uber1337h4xから来ているように見えるようにすることができます。これは明らかでよく知られています。 HTTPSから来る
任意のページはRFC2616 sec15ごとに参照するヘッダを送信しない：
参照ページがで転送された場合（非セキュア）HTTPリクエストでRefererヘッダフィールドを含めるべきではありませんクライアント安全なプロトコルです。 RFC2616 sec15あたりとして
ブレークのユーザビリティ：
リンクのソースは、個人情報であるかもしれない、あるいは民間の情報源を明らかにする可能性があるため、ユーザーがかどうかを選択できるようにすることを強く推奨されますRefererフィールドが送信されないかどうかを指定します。要するに
、あなたはより高いセキュリティを与えられていません。あなたのセキュリティは、OAuthレイヤーにある非常に安全でないトランスポートプロトコルを検査することではありません。また、ユーザビリティも壊します。
しないでください。
間違いなくより大きなセキュリティはありません。実際、私は私の質問にセキュリティという言葉は言及しなかった。ただ "利益"。私はセキュリティのために州を使用しており、それは十分です。私はDoS攻撃に照らして「合法」という言葉を使用しました。はい、彼らは偽造される可能性があり、httpsにリファラーがないと言っても、主流のプロバイダがリファラーを返すことはありえません。本質的に内容は他の答えと同じであるので、私はより早いものを受け入れる傾向があります。しかし、あなたは私のupvoteを持っています。 – necromancer
@agksmehxどのような有益な情報が、州のパラメータの存在が既に存在しないことをリファーラヘッダーが伝える可能性がありますか？ – Esailija
@エーザイジャ、私自身の答えをご覧ください。 – necromancer
stateパラメータが使用されているため、プレーンのセキュリティは、質問の問題ではありませんでした。私が念頭に置いていた
主な懸念は以下の通りであった。
最初の問題の唯一の解決策は、stateのほかにクッキーを設定することです。 refererは、ほとんどのプロバイダがhttpsを使用していなかった場合に役立ちます。
第2の問題はニュアンスがあります。誤って動作するエージェントは、悪意のあるエンティティによって直接制御される必要はありません。間接的な手段（一般的なハイジャックされたウェブサイト、ソーシャルエンジニアリング）によってリダイレクトされた通常のユーザーのブラウザかもしれません。
ニュアンスのため、refererヘッダーが偽造されていない可能性があります。ただし、httpsは意味のあるメリットを排除します。
POSTでCookieを設定していると、サードパーティのウェブサイトでこれらの設定が行われる可能性があり、ユーザーを大量にリダイレクトするハッキングされたWebサイトのため、OAuthレスポンスが氾濫しないためですOAuth。
これは明確な答え（または質問）ではありませんが、これは質問の背後にあるニュアンスを示していることをうまくいけばよいと思います。
「HTTP Referer」とそのようなヘッダは簡単にシミュレートできます。ユーザーは任意のヘッダーを送信できます。 – safarov
私はあなたが要求されたソース – safarov
を確認するためにIPアドレスを確認することができると思いますが、IPアドレスはユーザのものではありませんか？ – necromancer