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

> Cookie とは何か、またセッションと組み合わせてユーザー認証の追跡にどのように使用できるかを説明します。

# Cookies

Cookie は、Web サーバーがブラウザーに送信するデータ文字列です。ブラウザーが後で Web サーバーにリクエストを送信する際には、そのリクエストとともに同じ文字列も Web サーバーに送信します。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  以前の Auth0 では、`samesite` Cookie 属性のオプションは `true`、`false`、`strict`、`lax` でした。この属性を手動で設定しない場合、Auth0 では既定値として `false` が使用されていました。
  2020 年 2 月以降、Google Chrome v80 では Cookie の処理方法が変更されました。これを受けて、Auth0 では Cookie の処理方法に次の変更を実装しました。

  * `samesite` 属性が設定されていない Cookie は、`lax` に設定されます。
  * `sameSite=none` が設定された Cookie はセキュアである必要があります。そうでない場合、ブラウザーの cookie jar に保存できません。

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

Web サイトでは通常、ユーザーがページ間を移動しても認識できるように Cookie を使用し、毎回ログインを求められないようにしています。また、ユーザーが入力した情報を記憶するためにも Cookie を使用します。たとえば、e コマースサイトでは、ショッピングカートに入れた商品を記憶するために Cookie を使用します。

ユーザーは、ブラウザーの設定を変更することで、Cookie を受け入れるかどうかを選択できます。

<div id="cookie-based-authentication">
  ## Cookie ベースの認証
</div>

通常、トークンベースの認証の恩恵を最も受けるのは、シングルページアプリ (React、Vue、AngularJS + Node など) 、ネイティブモバイルアプリ (iOS や Android など) 、および Web API (Node、Ruby、ASP.NET、またはそれらを組み合わせて構築されたもの) です。一方、従来のサーバーサイド Web アプリケーションでは、Cookie ベースの認証が一般的に使用されてきました。

Cookie ベースの認証の実装方法は Web プラットフォームごとに異なりますが、最終的にはいずれも、認証済みユーザーを表す何らかの Cookie (サーバー上のセッションに関連付けられたもの) を設定することになります。各リクエストではその Cookie が送信され、セッションは何らかのストアからデシリアライズされます (単一サーバーであればメモリ、サーバーファームであれば永続ストレージなど) 。Auth0 では、対応する認証サブシステム (Node の passport、.NET や Java の IPrincipal など) と連携する SDK を、主要なプラットフォームの多く向けに提供しています。

認証が必要なアプリケーションを構築する場合は、リクエストのたびにユーザーが認証済みかどうかを判定するために、セッションと Cookie を使用できます。その方法としては、ステートフル Cookie またはステートレス Cookie を選択できます。

<div id="stateful-cookies">
  ### ステートフル Cookie
</div>

ステートフル Cookie には、セッション情報を保存するデータベースレコードを参照するポインターが含まれます。

**長所**:

* 保存できるセッション情報の量に制限がありません。
* ユーザーのセッションを簡単に無効化できます。データベースからレコードを削除するだけです。

**短所**:

* セッションデータを保存するためのデータベースが必要です (ただし、ほとんどの Web アプリケーションではすでに使用されています) 。
* ユーザーが送信する HTTP リクエストごとに、セッションの読み取り (場合によっては書き込み) のためにデータベースへのアクセスが必要になるため、レイテンシーが増加します。
* ユーザー数が多く、それに伴ってデータベースの読み取り/書き込みも増えると、スケーリングが難しくなることがあります。

<div id="stateless-cookies">
  ### ステートレス Cookie
</div>

ステートレス Cookie は自己完結型で、必要なセッション情報 (認証済みユーザーであればユーザー ID) をすべて含み、クライアント側に保存されます。外部からの改ざんを防ぐため、ステートレス Cookie は暗号化するか、少なくとも署名する必要があります。

**長所**:

* 容易に実装でき、特別なバックエンドも不要です。
* データベースを呼び出す必要がないため、レイテンシを低減できます。
* スケールしやすくなります。

**短所**:

* Cookie にはサイズ制限があるため (ほとんどのブラウザーで最大 4KB) 、保存できるセッション情報を制限する必要があります。セッション情報を複数の Cookie に分割することも可能ですが、推奨しません。
* 削除できるレコードがデータベースに存在しないため、セッションの失効が難しくなります。セッションを強制的にクリアするには、別の方法が必要です。
* 複数の Web サーバーを使用する場合は、すべてのサーバーが Cookie の暗号化/復号や署名に必要な鍵を持っていることを確認する必要があります。

<div id="learn-more">
  ## 詳しく見る
</div>

* [セッション](/ja/docs/manage-users/sessions)
* [Authentication API の Cookie](/ja/docs/manage-users/cookies/authentication-api-cookies)
* [SameSite Cookie 属性の変更](/ja/docs/manage-users/cookies/samesite-cookie-attribute-changes)
* [セキュリティ](/ja/docs/secure)