opendID接続プロバイダーを使用してログインし、コールバックwww.mysite.com/auth/callbackにリダイレクトされているとします。次に、受け取ったトークンを参照するIDを含むhttponly Cookieを作成し、ブラウザにwwww.mysite.com/で渡します。同じセッションクッキーを含むリクエストを別のサイトから送信するにはどうすればよいですか？ブラウザは要求元のドメインのCookieのみを渡しません。したがって、www.evil.comがwww.mysite.com/api/endpointにリクエストしようとすると、セッションCookieが渡されず、偽造リクエストが無効になりますか？セッションクッキーを使用するときにcsrfトークンが必要なのはなぜですか？
私はここに何か基本的なものがありませんか？
ウェブブラウザが別のドメインにリクエストを送信すると、そのドメインのCookieが既に存在するかどうかを確認するのに十分であり、そうであれば要求と共に送信されます。したがって、アプリにリクエストを送信しようとしているWebアプリケーションを使用している場合、そのリクエストはCookieと共に送信されます。偽造防止トークンの背後にあるアイデアは、Webブラウザがすべての情報を送信しても、アプリケーションから提出された正式な要求で作成したトークンとトークンが一致しない場合、失敗することです。
クロスオリジンのリクエストでクッキーを送信したくない場合は、クッキーにsamesiteフラグを使用できます。ここでは、StrictモードとLaxモードを選択できます。 Strictモードでは、発信元からのリクエストを介してサイトCookieを送信することはありません。そのため、送信されるセッションCookieを気にする必要はありません。ここで問題となるのは、別のサイトからリダイレクトされた場合、ここにいる場合、フェイスブックに移動しようとすると（厳密なモードを使用している場合）、Cookieは送信されず、もう一度認証することができます（アプリケーションやユーザーベースに応じて、迷惑な機能や良い機能になる可能性があります）。 Laxモードはかなり似ていますが、このモードでは、安全なHTTP動詞（GET、HEAD、OPTIONS、TRACE）を使用してCookieを送信するだけで、POST/PUT XSRF攻撃から保護されますGETリクエストのために厄介な振る舞いをしています。どちらがあなたのアプリにとってより良い選択肢になるかはあなた次第です。 XSRFとsamesiteクッキーについて
私は、ブラウザがURL 'evil.com'にあったならば、それは要求ドメインとして、関係なく、どのような要求のそのページに行われたことを使用することを想定。これは間違っています。ブラウザは、それぞれの要求のドメインに従ってCookieを追加します。 samesiteフラグは、csrfトークンの必要性に代わる面白い代替手段です。 – Panda