> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication APIクッキー

> Authentication APIクッキーとは何か、その用途と処理方法などについて説明します。

Auth0 Authentication APIは[シングルサインオン（SSO）](/docs/ja-JP/ja-jp/authenticate/single-sign-on)、[多要素認証（MFA）](/docs/ja-JP/ja-jp/secure/multi-factor-authentication)や[攻撃防御](/docs/ja-JP/ja-jp/secure/attack-protection)の機能に、HTTPクッキーのセットを使用します。以下の表は、Authentication APIが使用するクッキーの一部とその用途をまとめたものです。

<table class="table">
  <thead>
    <tr>
      <th><strong>クッキー</strong></th>
      <th><strong>機能</strong></th>
      <th><strong>目的</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`auth0`</td>
      <td>シングルサインオン</td>
      <td><a href="/docs/ja-JP/ja-jp/manage-users/sessions/session-layers">Auth0セッション層</a>を実装するために使用されます。</td>
    </tr>

    <tr>
      <td>`auth0_compat`</td>
      <td>シングルサインオン</td>
      <td>`sameSite=None`属性をサポートしないブラウザーでのシングルサインオンのためのフォールバッククッキー。</td>
    </tr>

    <tr>
      <td>`auth0-mf`</td>
      <td>多要素認証</td>
      <td>ある特定のデバイスの信頼レベルを構築するために使用されます。</td>
    </tr>

    <tr>
      <td>`auth0-mf_compat`</td>
      <td>多要素認証</td>
      <td>`sameSite=None`属性をサポートしないブラウザでの多要素認証のためのフォールバッククッキー。</td>
    </tr>

    <tr>
      <td>`a0_users:sess`</td>
      <td>クラシックログイン</td>
      <td>クラシックログインフローのCSRF保護のために使用されます。</td>
    </tr>

    <tr>
      <td>`a0_users:sess`</td>
      <td>クラシックログイン</td>
      <td>クラシックログインフローのCSRF保護のために使用されます。</td>
    </tr>

    <tr>
      <td>`did`</td>
      <td>攻撃防御</td>
      <td>攻撃防御のためのデバイスID。</td>
    </tr>

    <tr>
      <td>`did_compat`</td>
      <td>攻撃防御</td>
      <td>`sameSite=None`属性をサポートしないブラウザーでの異常検出のためのフォールバッククッキー。</td>
    </tr>
  </tbody>
</table>

<Warning>
  Auth0では、標準的な認証クッキーに変更が加えられるシナリオをサポートしていません。これには、非標準ブラウザー・ブラウザーアドオン・HTTPプロキシを介したcookie属性の追加・変更・削除が含まれます。
</Warning>

<div id="cookies-and-custom-domains">
  ## クッキーとカスタムドメイン
</div>

[カスタムドメイン](/docs/ja-JP/ja-jp/customize/custom-domains)を使用している場合には、Authentication APIからのクッキーがカスタムホスト名、または<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-JP/ja-jp/glossary?term=auth0-dashboard" tip="Auth0 Dashboard: サービスを構成するためのAuth0の主製品。" cta="用語集の表示">Auth0 Dashboard</Tooltip>でセットアップしたCNAMEに送信されます。それぞれのクッキーのドメイン属性は、そのクッキーが有効なドメインを指定するものですが、ドメイン属性のドメインと送信先が一致している場合は、要求ヘッダーにクッキーが定義されます。

ドメインが指定されていない場合、ドメイン属性はデフォルトで要求ホストになります。IETFの[HTTP State Management Mechanism](https://datatracker.ietf.org/doc/html/rfc2109#section-2)仕様に従ってクッキーを親ドメインに設定している場合には、親ドメインにあるすべてのサブドメインでクッキーが共有されます。

たとえば、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に大きすぎるサイズのクッキーが送信されないようにしてください。カスタムドメインでのクッキーの動作については、「[クッキーをオリジンサーバーに送信する](https://datatracker.ietf.org/doc/html/rfc2109#section-4.3.4)」をお読みください。

<div id="learn-more">
  ## もっと詳しく
</div>

* [sameSiteクッキー属性の変更](/docs/ja-JP/ja-jp/manage-users/cookies/samesite-cookie-attribute-changes)
* [ドメインを確認する](/docs/ja-JP/ja-jp/troubleshoot/basic-issues/verify-domain)
* [多要素認証問題をトラブルシューティングする](/docs/ja-JP/ja-jp/troubleshoot/authentication-issues/troubleshoot-mfa-issues)