sameSiteクッキー属性の変更
認証とセッションの維持に使用されるCookieは、属性を設定することで保護できます。Auth0は、次の目的でCookieを使用します。
form_postを使用したOIDC EnterpriseSAML HTTP-POSTバインディング
Webメッセージ（別名
checkSession）
SameSite属性
Set-cookie HTTP応答ヘッダーにSameSite cookie属性を追加して、ブラウザの動作を制限できます。HTTP要求をトリガーしたインタラクションの種類に基づいて、ブラウザがCookieのkey=valueのペアを送信できないようにすることができます。
許容される属性値は次のとおりです。
| 属性 | 説明 |
|---|---|
strict |
ユーザーがWebサイトのオリジン紐づけ内を移動している場合にクッキーを送信する |
lax |
ユーザーがサードパーティのコンテキスト（iframesまたはposts）でなくドメイン間を移動している場合にクッキーを送信する |
none |
要求とともにWebサイトのオリジン紐づけを超えてクッキーを送信するその他の条件が存在しない限り（すなわち、サードパーティのクッキーがブロックされていない限り）、クッキーを送信しないでください。 |
よく知られているCookie属性には次のものがあります。
| 属性 | 説明 |
|---|---|
httpOnly |
HTTPリクエストでのみクッキーを送信することができます。Javascriptのdocument.cookieでは読み取りできません |
secure |
ブラウザーでクッキーを安全なコンテキストのみに送信することができます。コンテキストが安全かどうかはブラウザーに左右されますが、これには通常、HTTPSを使用する必要があります |
max-age / expires |
クッキーが**session（セッション）クッキー（ブラウザーがセッションを終了する際に破棄されるクッキー）、またはpersistent（永続的な）**クッキー（ブラウザーセッションが終了した後でも存続するクッキー）かどうかを制御します |
ブラウザは、受信時にヘッダーを解析し、それに応じてCookie jarを更新します。
ブラウザCookieの変更
2020年2月時点で、Google Chrome v80によるCookieの取り扱いが変わりました。2020年2月現在、Google Chrome v80ではCookieの処理方法が変更されました。
samesite属性が設定されていないクッキーは、laxに設定されますsameSite=noneのCookieは、セキュリティ保護が必要です。保護されていない場合、ブラウザーに保存できません
これらの変更は、セキュリティの強化とCSRF攻撃からの防御を目的としています。
これらの変更は、次のCookieに影響します。
auth0（ユーザーセッションを処理）auth0-mf（多要素認証に関連する情報を処理）did（デバイス/ユーザーエージェントの識別子）
これらのCookieに対して、Auth0は次の操作を実行します。
SameSite属性をnoneに設定し、CookieでHTTPSの使用を要求します（環境に関係なく）レガシーブラウザが
SameSiteをNoneに設定できないときにフォールバックCookieを設定します。これらのフォールバックCookieは、auth0_compat、auth0-mf_compatおよびdid_compatです。
下の図は、新しいインタラクション中に何が起こるかを示しています。エンドユーザーは、以前に訪問したことのないページを要求します。訪問者が戻ってきたときにサーバーがレンダリング方法を変更し、表示されたCookieを設定します。set-cookieヘッダーの灰色の部分は、実際のCookie key=valueです。赤い部分は、ブラウザがCookie jarに保存するCookie属性で、後で要求に Cookie key+valueのペアを含めるかどうかを決定します。
次の図は、同じブラウジングセッションを使用して同じ要求を行った場合に何が起こるかを示しています。要求は同じサーバーに送信され、Cookie 属性は表示された Cookie の送信を禁止していないため、要求にCookieヘッダーとして自動的に含められます。サーバーは、このCookieを受信したという事実に基づいて、異なる応答をします。
影響のある機能
次の表は、SameSite属性の変更がアプリにどのような影響を与えるかを示しています。
| アプリ動作 | 変更による影響 |
|---|---|
Webサイトがhttps://でない場合、クッキーがsameSite=noneと設定されます |
あり |
クッキーに明示的なsameSite属性の値が設定されておらず、cross-originコンテキスト（HTTP form_postやiframeを埋め込むなど)で必要です |
あり |
| ネイティブアプリ（すべてがクッキー + Webベースでない） | なし（M2M） |
明示的なsameSiteクッキーの属性値が既に設定されています |
なし |
| 同じeTLD+1に異なるサブドメインが存在します（アプリがカスタムドメインのAuth0テナントと同じeTLD+1にある） | 可能性あり |
セッションのあるWebアプリ（ユーザー設定、ショッピングカートなどを保存するため）を使用していて、ユーザーがGoogle、Github、Auth0などのIDプロバイダーを使用してサインインできるようにする場合、その機能を実現するためにCookieに依存します。ブラウザのCookieの動作の変更により、ユーザー エクスペリエンスが損なわれる可能性があります。たとえば、Google Chromeは、Webアプリケーションと互換性がない可能性がある変更を展開した最初のブラウザベンダーです。
SameSiteをundefinedに設定するGoogle ChromeおよびMicrosoft Edgeの仕様が、SameSiteのデフォルトをnoneからlaxに変更されたことに気付くかもしれません。
たとえば、新しいUIを構築し、Auth0ゲートウェイ経由でプロキシするサービスがいくつかあるとします。このゲートウェイで、Cookieセッションを作成します。クロスオリジン要求を行うと、Javascriptコンソールに次の警告が表示される場合があります。
クロスサイトリソース（URL）に関連付けられた Cookie が SameSite 属性なしで設定されました。Chromeの将来のリリースでは、クロスサイト要求がSameSite=NoneおよびSecureで設定されている場合にのみ、Cookieが配信されます。開発者ツールの［Application（アプリケーション）］>［Storage（ストレージ）］>［Cookies］でCookieを確認し、詳細はhttps://www.chromestatus.com/feature/5088147346030592およびhttps://www.chromestatus.com/feature/5633521622188032で確認できます。
必要なアクション
この変更に備えるには、次の操作を行う必要があります。
サポートされていないブラウザのリストを確認します。
Auth0 とやり取りするときに
response_mode=form_postを使用する場合は、アプリケーションでSameSite=noneを使用するように設定します（Chromeはlocalhostの場合でも例外を設けないことに注意してください）SameSite属性がNoneに等しい場合は、Cookieをセキュアとして設定します。そうでない場合、ブラウザによって拒否されます。コールバックURLにHTTPを使用する場合、そのようなCookieを使用して認証要求のstate/nonceをバインドすると、コールバックURLが壊れます。したがって、HTTPSを使用するか、SameSite=laxに設定する必要があります。