> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# sameSiteクッキー属性の変更
> SameSite Cookie属性などのブラウザの変更が、サードパーティのドメインからのコンテンツを埋め込むWebアプリケーションにどのように影響するかについて説明します。
認証とセッションの維持に使用されるCookieは、属性を設定することで保護できます。Auth0は、次の目的でCookieを使用します。
* `form_post`を使用したOIDC Enterprise
* SAML HTTP-POSTバインディング
* Webメッセージ（別名`checkSession`）
## SameSite属性
`Set-cookie` HTTP応答ヘッダーに[SameSite cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)属性を追加して、ブラウザの動作を制限できます。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で確認できます。`
## 必要なアクション
この変更に備えるには、次の操作を行う必要があります。
* [サポートされていないブラウザ](https://www.chromium.org/updates/same-site/incompatible-clients)のリストを確認します。
* Auth0 とやり取りするときに`response_mode=form_post`を使用する場合は、アプリケーションで`SameSite=none`を使用するように設定します（Chromeは`localhost`の場合でも例外を設けないことに注意してください）
* `SameSite`属性が`None`に等しい場合は、Cookieをセキュアとして設定します。そうでない場合、ブラウザによって拒否されます。コールバックURLにHTTPを使用する場合、そのようなCookieを使用して認証要求のstate/nonceをバインドすると、コールバックURLが壊れます。したがって、HTTPSを使用するか、`SameSite=lax`に設定する必要があります。