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

# Cookie

Cookie は、ウェブサーバーがブラウザーに送信するデータ文字列です。ブラウザーが後でウェブサーバーに request を送信する際には、その request と一緒に同じ文字列もウェブサーバーに送信します。

<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>

ウェブサイトでは通常、ユーザーがページ間を移動しても認識できるように Cookie を使用し、毎回ログインし直さなくて済むようにしています。また、ユーザーが入力した情報を記憶するためにも Cookie を使用します。たとえば、EC サイトでは、ショッピングカートに入れた商品を記憶するために Cookie を使用します。

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

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

通常、シングルページアプリ (React、Vue、AngularJS + Node など) 、Native モバイルアプリ (iOS や Android など) 、そして Web API (Node、Ruby、ASP.NET、またはそれらを組み合わせて構築されたもの) は、トークン ベースの認証のメリットを最も受けやすい種類です。一方、従来型のサーバーサイド Web アプリケーションでは、従来から Cookie ベースの認証が使われてきました。

Cookie ベースの認証は Web プラットフォームごとに実装方法が異なりますが、最終的にはどの場合も、認証済みユーザーを表す何らかの Cookie (サーバー上のセッションにひも付いたもの) を設定することになります。リクエストのたびにその Cookie が送信され、セッションはどこかのストアからデシリアライズされます (単一サーバーならメモリ内、サーバーファームなら永続ストレージなど) 。また、対応する認証サブシステム (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は自己完結型で、必要なセッション情報 (認証済みユーザーの場合はuser ID) をすべて含み、クライアント側に保存されます。外部からの改ざんを防ぐため、ステートレスCookieは暗号化するか、少なくとも署名する必要があります。

**長所**:

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

**短所**:

* Cookieにはサイズ制限があるため (ほとんどのブラウザーで最大4KB) 、保存できるセッション情報を制限しなければなりません。セッション情報を複数のCookieに分割することもできますが、お勧めしません。
* 削除できるデータベース上の記録がないため、セッションを取り消しにくくなります。セッションを強制的にクリアするには、別の方法を検討する必要があります。
* 複数のWebサーバーを使用する場合は、すべてのサーバーがCookieの暗号化/復号や署名に必要なキーを持っていることを確認する必要があります。

<div id="learn-more">
  ## 詳細はこちら
</div>

* [セッション](/docs/ja-jp/manage-users/sessions)
* [Authentication API の Cookie](/docs/ja-jp/manage-users/cookies/authentication-api-cookies)
* [SameSite Cookie Attribute の変更点](/docs/ja-jp/manage-users/cookies/samesite-cookie-attribute-changes)
* [Secure](/docs/ja-jp/secure)