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

# クッキー

> クッキーとは何か、ユーザーの認証を追跡するためにセッションでどのように使用されるのかについて説明します。

クッキーはWebサーバーがブラウザーに送信するデータ列です。ブラウザーがその後、そのWebサーバーに要求を送信する際には、要求と一緒に同じデータ列が送信されます。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Autho0ではこれまで、クッキーの`samesite`属性には`true`、`false`、`strict`、`lax`のオプションがありました。属性が手動で設定されていない場合、Auth0はデフォルト値の`false`を使用していました。2020年2月より、Google Chrome v80によるクッキーの取り扱いが変わりました。Auth0はこれを受けて、クッキーの処理方法を以下のように変更しました。

  * `samesite`属性が設定されていないクッキーは、`lax`に設定されます。
  * `sameSite=none`のクッキーは、セキュリティ保護が必要です。そうしないとブラウザーのcookie jarに保存できません。

  これらの変更は、セキュリティの強化とCSRF攻撃からの防御を目的としています。
</Callout>

Webサイトは通常クッキーを使って、ユーザーがページを移動しても確実に認識されるようにします。これで、ページを移動するたびに毎回ログインする必要がなくなります。また、Webサイトはクッキーを使って、ユーザーが入力した情報を記憶します。たとえば、Eコマースサイトは、カートに入れられた商品を覚えておくためにクッキーを使用します。

ユーザーは、ブラウザーの設定を変更して、クッキーの受け入れを選択することができます。

## クッキーベースの認証

通常、シングルページアプリ（React・Vue・AngularJS + Nodeなど）、ネイティブモバイルアプリ（iOS・Androidなど）とWeb API（Node・Ruby・ASP.NETやその混合）には、トークンベースの認証が最も適しています。サーバー側のWebアプリケーションでは、伝統的にクッキーベースの認証が使用されてきました。

Webプラットフォームはそれぞれ、クッキーベースの認証を異なる方法で実装していますが、結局のところ、認証済みのユーザーを表すのに（サーバー上のセッションに紐づけられた）何らかのクッキーを設定しています。それぞれの要求についてそのクッキーが送信され、何らかのストア（1台のサーバーであればメモリ内、サーバーファームであれば何らかの永続ストレージ）からセッションが非直列化されます。Auth0ではほとんどのプラットフォーム用にSDKを提供して、対応する認証サブシステム（nodeのpassport、.NETやJavaのIPrincipalなど）と結び付けます。

認証を要求するアプリケーションの構築では、それぞれの要求時にユーザーが認証済みかを判断するために、セッションやクッキーを使用することができます。クッキーはステートフルとステートレスから選ぶことができます。

### ステートフルクッキー

ステートフルクッキーには、セッション情報を保管するデータベースレコードへのポインターが含まれます。

**利点**

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

**欠点**

* セッションデータをデータベースに保管する必要があります（ただし、ほとんどのWebアプリケーションはすでにこれを行っています）。
* ユーザーがHTTP要求を行うたびにセッションを読み取る（時には書き込む）のにデータベースを呼び出す必要があるため、遅延が増加します。
* ユーザーの数が多く、データベースに対する読み取りや書き込みが多くなる場合には、規模の調整が困難なこともあります。

### ステートレスクッキー

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

**利点**

* 手軽に実装できます。特別なバックエンドは必要ありません。
* データベースを呼び出す必要がないため、遅延が低減されます。
* 規模の調整が簡単です。

**欠点**

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

## もっと詳しく

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