SameSite Cookie 属性の変更

SameSite Cookie 属性などのブラウザーの変更が、サードパーティ ドメインのコンテンツを埋め込む Web アプリケーションにどのような影響を与えるかを説明します。

認証やセッションの維持に使用される Cookie は、属性を設定することでセキュリティを強化できます。Auth0 では、次の用途で Cookie を使用します。

• form_post を使用する OIDC Enterprise
• SAML HTTP-POST バインディング
• Web メッセージ (checkSession とも呼ばれます)

​

SameSite 属性

ブラウザーの動作を制限するために、set-cookie HTTP レスポンスヘッダーに SameSite cookie 属性を追加できます。これにより、HTTP リクエストを引き起こした操作の種類に応じて、ブラウザーが cookie の key=value ペアを送信しなくなる場合があります。

使用できる属性値は次のとおりです。

属性	説明
strict	ユーザーが Web サイトのオリジン内を移動している場合に cookie を送信します
lax	ユーザーがドメイン間を移動している場合は cookie を送信しますが、サードパーティコンテキスト (iframe や POST) では送信しません
none	Web サイトのオリジンをまたぐリクエストでも cookie を送信します。ただし、他の条件がある場合 (例: サードパーティ cookie がブロックされている場合) は送信されません。

よく使われる cookie 属性には、次のものがあります。

属性	説明
httpOnly	cookie を HTTP リクエストでのみ送信できるようにします。JavaScript の document.cookie では読み取れません
secure	ブラウザーが安全なコンテキストに対してのみ cookie を送信できるようにします。コンテキストが安全と見なされるかどうかはブラウザーによって異なりますが、通常は HTTPS の使用が必要です
max-age / expires	cookie が セッション cookie (例: ブラウザーのセッション終了時に破棄される) か、永続 cookie (例: ブラウザーのセッション終了後も保持される) かを制御します

ブラウザーは受信時にヘッダーを解析し、それに応じて cookie jar を更新します。

​

ブラウザの Cookie に関する変更

2020 年 2 月以降、Google Chrome v80 では Cookie の扱いが変更されました。これに伴い、Auth0 でも Cookie の処理に次の変更を実装しました。

• SameSite 属性が設定されていない Cookie は、lax として設定されます
• SameSite=none が設定された Cookie にはセキュリティ保護が必要です。そうでない場合、ブラウザの Cookie jar に保存できません

これらの変更の目的は、セキュリティを向上させ、CSRF 攻撃の緩和に役立てることです。

これらの変更は、次の Cookie に影響します。

• auth0 (ユーザーセッションを処理)
• auth0-mf (多要素認証 に関連する情報を処理)
• did (デバイス / ユーザーエージェントの識別子)

これらの Cookie について、Auth0 は次のように動作します。

• SameSite 属性を none に設定し、Cookie で HTTPS の使用を必須にします (環境に関係なく)
• レガシーブラウザが SameSite を None に設定することをサポートしていない場合に備えて、フォールバック Cookie を設定します。これらのフォールバック Cookie は、auth0_compat、auth0-mf_compat、did_compat です

以下の図は、初回のやり取りで何が起こるかを示しています。エンドユーザーは、これまでアクセスしたことのないページをリクエストします。サーバーは、訪問者が再訪したときのレンダリング方法を変更し、seen Cookie を設定します。set-cookie ヘッダーの灰色の部分は、実際の Cookie key=value. です。赤色の部分は、後でリクエストに Cookie の key+value ペアを含めるかどうかを判断するために、ブラウザが Cookie jar に保存する Cookie 属性です。

次の図は、同じブラウジングセッションで同じリクエストを行った場合に何が起こるかを示しています。リクエストは同じサーバーに送られ、Cookie 属性によって seen Cookie の送信が禁止されていないため、その Cookie はリクエストの Cookie ヘッダーに自動的に含まれます。サーバーは、この Cookie を受け取ったことに基づいて、異なる応答を返すようになります。

​

影響を受ける機能

以下の表は、SameSite 属性の変更がアプリにどのような影響を及ぼす可能性があるかを示しています。

App Behavior	Affected by Change
ウェブサイトが https:// ではない場合に、sameSite=none として設定される Cookie	はい
Cookie に明示的な sameSite 属性値が設定されておらず、クロスオリジンのコンテキスト (HTTP form_post、iframe の埋め込みなど) で必要になる	はい
ネイティブアプリ (Cookie とウェブベース以外のすべて)	いいえ (M2M)
すでに明示的な sameSite Cookie 属性値を設定している	いいえ
同じ eTLD+1 上の別のサブドメイン (アプリが Auth0 テナントのカスタムドメインと同じ eTLD+1 上にある)	場合によっては影響あり

セッションを使用するウェブアプリ (たとえば、ユーザー設定やショッピングカートなどを保存するもの) を利用していて、さらに Google、GitHub、Auth0 などの IDプロバイダー を使ったサインインをユーザーに許可している場合、その機能は Cookie に依存しています。ブラウザにおける Cookie の動作変更によって、ユーザー体験が損なわれる可能性があります。たとえば Google Chrome は、この変更を最初に導入したブラウザベンダーであり、その変更はウェブアプリケーションと互換性がない可能性があります。

Google Chrome と Microsoft Edge では、SameSite を未定義に設定した場合の仕様が変更され、SameSite のデフォルト値が none ではなく lax になったことに気付くかもしれません。

たとえば、新しい UI を構築し、Auth0 ゲートウェイ経由でプロキシする複数のサービスがあるとします。このゲートウェイで Cookie セッションを作成している場合、クロスオリジンリクエストを行うと、JavaScript コンソールに次の警告が表示されることがあります。

A cookie associated with a cross-site resource (URL) was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032

​

実施が必要な対応

この変更に備えるには、次の対応を行ってください。

• サポート対象外のブラウザーの一覧を確認します。
• Auth0 とやり取りする際に response_mode=form_post を使用している場合は、アプリケーションが SameSite=none を使用するように設定します (Chrome は localhost に対しても例外を設けない点に注意してください)
• Cookie の SameSite 属性が None の場合は、その Cookie を secure に設定します。そうしないと、ブラウザーに拒否されます。コールバック URL に HTTP を使用している場合、そのような Cookie を認可リクエストの state/nonce の関連付けに使うと、動作しなくなります。したがって、HTTPS を使用するか、SameSite=lax を設定する必要があります