| クッキー | 機能 | 目的 |
|---|---|---|
auth0 | シングルサインオン | Auth0セッション層を実装するために使用されます。 |
auth0_compat | シングルサインオン | sameSite=None属性をサポートしないブラウザーでのシングルサインオンのためのフォールバッククッキー。 |
auth0-mf | 多要素認証 | ある特定のデバイスの信頼レベルを構築するために使用されます。 |
auth0-mf_compat | 多要素認証 | sameSite=None属性をサポートしないブラウザでの多要素認証のためのフォールバッククッキー。 |
a0_users:sess | クラシックログイン | クラシックログインフローのCSRF保護のために使用されます。 |
a0_users:sess | クラシックログイン | クラシックログインフローのCSRF保護のために使用されます。 |
did | 攻撃防御 | 攻撃防御のためのデバイスID。 |
did_compat | 攻撃防御 | sameSite=None属性をサポートしないブラウザーでの異常検出のためのフォールバッククッキー。 |
Auth0では、標準的な認証クッキーに変更が加えられるシナリオをサポートしていません。これには、非標準ブラウザー・ブラウザーアドオン・HTTPプロキシを介したcookie属性の追加・変更・削除が含まれます。
クッキーとカスタムドメイン
カスタムドメインを使用している場合には、Authentication APIからのクッキーがカスタムホスト名、またはでセットアップしたCNAMEに送信されます。それぞれのクッキーのドメイン属性は、そのクッキーが有効なドメインを指定するものですが、ドメイン属性のドメインと送信先が一致している場合は、要求ヘッダーにクッキーが定義されます。 ドメインが指定されていない場合、ドメイン属性はデフォルトで要求ホストになります。IETFのHTTP State Management Mechanism仕様に従ってクッキーを親ドメインに設定している場合には、親ドメインにあるすべてのサブドメインでクッキーが共有されます。 たとえば、CNAMEをlogin.example_domain.comに設定し、それがexample_domain.comのサブドメインだとします。他のアプリケーションをapp1.example_domain.comやapp2.example_domain.comなどとして親ドメインでホストします。ユーザーがlogin.example_domain.comを表示すると、app1.example_domain.comやapp2.example_domain.comからのクッキーが要求と一緒にAuth0 Authentication APIに送信される可能性があります。
プラットフォームを保護するため、そして、これらのクッキーがサイズとして大きくなる可能性や他のサブドメインと共有される可能性を懸念して、Auth0はヘッダーのサイズが大きすぎる（数キロバイト）要求を拒否することがあります。アプリケーションを設計する際には、Auth0 Authentication APIに大きすぎるサイズのクッキーが送信されないようにしてください。カスタムドメインでのクッキーの動作については、「クッキーをオリジンサーバーに送信する」をお読みください。