Google+ログイン-ワンタイムコードフローと純粋なサーバー側フロー
私はGoogle+サインイン、より具体的には、サーバー側のフローに関するドキュメントを読んでいます。 （ https://developers.google.com/+/web/signin/redirect-uri-flow ）とあり、1回限りのコードフローには、純粋なサーバーサイドフローよりもセキュリティ上の利点があります。それは言う：
「この1回限りのコードフローには、純粋なサーバー側フローやサーバーへのアクセストークンの送信よりもセキュリティ上の利点があります。」
ワンタイムコードフローとサーバーへのアクセストークンの送信の利点はわかりますが、ワンタイムコードフローと純粋なサーバーサイドフローの利点は実際にはわかりません。誰かがそれらのいくつかを指摘できるかどうか疑問に思っていました。
唯一のセキュリティ上の利点は、ワンタイムコードフローを使用する場合、クライアントのブラウザコンポーネントとサーバーコンポーネントがそれぞれ独自のトークンを取得することです。純粋なサーバー側フローでは、サーバーのみがトークンを取得し、Webアプリケーションフローはクライアントのみがトークンを取得します。トークンをクライアントからサーバーに、またはその逆に送信すると、エンドユーザーが特定のリスクにさらされます。ワンタイムコードフローを使用すると、クライアント<->サーバーからのトークンの送信がなく、トークンが危険にさらされるリスクが少なくなります。
「この1回限りのコードフローにはセキュリティ上の利点があります...」Webアプリケーションが受ける可能性のある最も危険な攻撃の1つを考慮している間、ステートメントは絶対に有効です。これは、クロスサイトリクエストフォージェリ（略してCSRF）です。
ワンタイムコードの利点を説明する前に、CSRFの概念について説明します。 CSRFは、OWASPリストで2013年の最も危険な脆弱性の8位です。WebアプリケーションがCSRFに対して脆弱である場合、ユーザーがサインインしている必要があれば、ユーザー側でハッカーのスクリプトを実行できます。基本的には攻撃者がURLまたはPOST悪意のあるコードを含むリクエストを作成する場合、ユーザーのセッションCookieを取得してハッカーに送信するためのJSコードである可能性があります。これらのURLが送信されるようになります。 POSTリクエストはハッカーによって自分のサイトに実装され、同じ方法で被害者にリンクが与えられます。ユーザーがログインしているので、リンクをクリックすると、ユーザーエンドで隠しスクリプトが実行され、ハッキングされます。
CSRFに対して可能な唯一の防止方法は、各ページにトークンを実装することです。ユーザーが自分のアカウントにログインすると、サーバーはCSRFトークンをWebアプリケーションの各ページに割り当てます。これで、リンクがクリックされるたびに、CSRFトークンがサーバーに送信され、サーバーはトークンを受け入れる場合にのみ許可を与えます。電子メールまたはチャットからクリックされたリンクは別のCSRFトークンを持つため、この攻撃を防ぐことができると考える必要があります。