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

> Auth0 セッションを使用してユーザーの認証状態を管理する方法を学びます。

# セッション

セッションとは、一定期間におけるユーザーとアプリケーションの間の一連のやり取りです。1 つのセッションには複数のアクティビティ (ページビュー、イベント、ソーシャルでのやり取り、e コマースでの取引など) が含まれる場合があり、ユーザーが接続している間、この情報を一時的に保存できます。

標準的な Set-Cookie ヘッダーの実装では、ユーザーが Web サイトを離れるかブラウザーを閉じると、セッションは終了します。ユーザーが毎回ログインしなくて済むように、アプリケーションは <Tooltip tip="セッション Cookie: 存在する場合、ユーザーが認証済みと見なされるエンティティです。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=session+cookie">セッション Cookie</Tooltip> に最大有効期間を設定することで、セッションを延長できます。セッションは、ユーザーがログアウトしたとき、またはセッションの有効期間の制限に達したときに終了します。

詳しくは、[Auth0 Privacy and Cookie Policy](https://auth0.com/privacy) をご確認ください。

<div id="session-use-cases">
  ## セッションのユースケース
</div>

Auth0 は、アプリケーションを通じて認証されたすべてのユーザーについて、ログインセッションを維持します。ユーザーが新たに標準のログインを行うと、Auth0 はそのログインセッションをリセットします。また、パスワード、メールアドレス、電話番号、またはユーザー名を更新すると、そのユーザーの Auth0 セッションも期限切れになります。

認証が必要なアプリケーションを構築する場合、リクエストが発生するたびにユーザーが認証済みかどうかを判断するために、セッションを利用できます。アプリの構築方法によっては、ユーザーにより安全な体験を提供するために、異なる <Tooltip tip="Authorization Flow: OAuth 2.0 フレームワークで指定される認可グラント（またはワークフロー）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+flows">認可フロー</Tooltip> が推奨されます。

たとえば、storezero.io という OIDC 準拠の (<Tooltip tip="OpenID: アプリケーションがログイン情報を収集・保存することなく、ユーザーの本人確認を行えるようにする認証のためのオープン標準。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Connect) Web サイトを考えてみましょう。

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5XXxdX4fuApQtAapQfZU1b/2fd9161af60962e3de3fc951d95b83d1/use-case-storezero.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=acce140587a28a365274a86cf166a879" alt="EC サイト Storezero.io の例" width="889" height="987" data-path="docs/images/cdy7uua7fh8z/5XXxdX4fuApQtAapQfZU1b/2fd9161af60962e3de3fc951d95b83d1/use-case-storezero.png" />
</Frame>

Storezero.io では、購入を完了するためにユーザーがログインする必要はありません。ただし、サイトの My Account セクションを表示するには、ユーザーはログインする必要があります。

以下に挙げるユースケースでは、ユーザーが購入手続きに進む前に過去の注文を確認したい状況を考えてみましょう。そのためには、My Account セクションの All Orders ページに移動し、ログインを求められます。

<div id="login-flows">
  ### ログインフロー
</div>

ほとんどの種類のアプリケーション (web app、シングルページアプリケーション、ネイティブアプリなど) では、ログイン認証を行うために [PKCE を使用した Authorization Code フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) を使用すべきです。このフローでは、認可コードをトークンと交換します。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  PKCE を使用した Authorization Code フローは、バックエンドを持たない シングルページアプリケーション で従来使われていた implicit flow に代わるものです。最適なセキュリティを確保するため、新規開発ではこのフローを使用する必要があります。また、implicit flow を使用している既存のアプリケーションを、PKCE で保護された認可コードフローへ移行することも強く推奨されます。
</Callout>

<div id="user-logs-in-with-username-and-password">
  #### ユーザーがユーザー名とパスワードでログインする
</div>

この例では、ユーザーはユーザー名とパスワードを使って手動でログインします。

1. Auth0 の SDK がローカルセッションを作成し、ユーザーを Auth0 の認可サーバー (`/authorize` エンドポイント) にリダイレクトします。
2. 認可サーバーがセッションを作成し、その後ユーザーをログインと認可のプロンプトにリダイレクトします。
3. ユーザーはユーザー名とパスワードを使用して認証を行います。
4. Auth0 の認可サーバーは、ユーザーがログイン済みであることを示すために、先に作成されたユーザーのセッションを更新します。
5. 使用するフローに応じて、認可サーバーは ID トークンまたは認可コードのいずれかとともに、ユーザーをアプリケーションに戻します。
6. アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。

このフローでは、2 つのセッションが作成されます。

* **ローカルセッション** (storezero.io) 。これは、ユーザーが認証済みかどうかをアプリケーションに示します。
* **<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の境界を定義するのに寄与する中央サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+server">認可サーバー</Tooltip> セッション** (storezero.auth0.com) 。これは、ユーザーが認証済みかどうかをサーバーに示します。サーバーセッションでは、認証に関する詳細を任意で追跡することもできます。

  * たとえば、認可サーバーは、ユーザーが [多要素認証 (MFA) ](/docs/ja-jp/secure/multi-factor-authentication) を利用したかどうかを追跡できます。こうした情報は、ユーザーが次に認可サーバーにアクセスしたときに、ログインを求めるべきか、多要素認証を求めるべきかを判断するために使用できます。

<div id="user-logs-in-with-identity-provider">
  #### ユーザーがアイデンティティプロバイダーでログインする
</div>

この例では、ユーザーはユーザー名とパスワードではなく、Facebook でログインすることを選択します。

1. Auth0 の SDK がローカルセッションを作成し、ユーザーを Auth0 の認可サーバー (`/authorize` エンドポイント) にリダイレクトします。
2. 認可サーバーがセッションを作成し、ユーザーをログインおよび認可のプロンプトにリダイレクトします。
3. Facebook でログインすることを選ぶと、認可サーバーはユーザーを Facebook にリダイレクトします。
4. Facebook がセッションを作成してユーザーを認証します。その後 Facebook は、ユーザーがログイン済みであることを示すようにセッションを更新します。
5. Facebook はユーザーを Auth0 の認可サーバーに戻します。その後、認可サーバーはユーザーがログイン済みであることを示すようにセッションを更新します。
6. 使用するフローに応じて、認可サーバーは ID トークンまたは認可コードとともに、ユーザーをアプリケーションに戻します。
7. アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。

このシナリオでは、3 つのセッションが作成されます。**ローカルセッション** (storezero.io) 、**認可サーバーセッション** (storezero.auth0.com) 、そして **<Tooltip tip="アイデンティティプロバイダー（IdP）: デジタルアイデンティティを保存および管理するサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=identity+provider">アイデンティティプロバイダー</Tooltip> (IdP) セッション** (facebook.com) です。

Facebook のサーバー上の IdP セッションはユーザーを認証し、シームレスな <Tooltip tip="シングルサインオン（SSO）: ユーザーが 1 つの applicaton にログインした後、そのユーザーをほかのアプリケーションにも自動的にログインさせるサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SSO">SSO</Tooltip> 体験を提供します。ユーザーはすでに Facebook にログインしている可能性が高いため、Facebook の資格情報を手動で入力しなくても認証されることがよくあります。

<div id="session-management-for-spas">
  ### SPA のセッション管理
</div>

前の例では、ユーザーがいずれかのログインフローを開始すると、ローカルセッションが作成されます。このローカルセッションによって、ユーザーのログイン状態を維持し、いつ再認証が必要になるかを判断できます。

ただし、シングルページアプリケーション (SPA) など、バックエンドを持たないアプリケーションでは、ローカルセッションは利用できません。代わりに、これらのアプリケーションでは、ユーザーのログイン状態を維持するために、[サイレント認証](/docs/ja-jp/authenticate/login/configure-silent-authentication) と呼ばれる別の方法を使用します。

サイレント認証では、ユーザーがいつ再認証する必要があるかを判断するために、認可サーバー上のセッションを使用します。非表示の iframe により、`prompt=none` パラメーターを付けた認証リクエストが認可サーバーにリダイレクトされます。このパラメーターは、サーバーがユーザーに入力を求めないようにするものです。

* 認可サーバー上のセッションの有効期限が切れていなければ、処理はシームレスに継続されます。サーバーは、`postMessage` を利用する WMRM (Web Message Response Mode) を通じて、<Tooltip tip="アクセストークン: API へのアクセスに使用される認可資格情報で、不透明な文字列または JWT の形式を取ります。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">アクセストークン</Tooltip>を送信します。
* 認可サーバー上のセッションの有効期限が切れている場合、またはユーザーがログアウトした場合、iframe 内のリダイレクトはエラーを返します。その場合、アプリケーションは再認証のためにユーザーを認可サーバーへ誘導する必要があります。

<div id="learn-more">
  ## さらに詳しく
</div>

* [セッションレイヤー](/docs/ja-jp/manage-users/sessions/session-layers)
* [セッションの有効期間の制限](/docs/ja-jp/manage-users/sessions/session-lifetime-limits)
* [セッションの有効期間の設定](/docs/ja-jp/manage-users/sessions/configure-session-lifetime-settings)
* [Cookie](/docs/ja-jp/manage-users/cookies)
* [SameSite Cookie 属性の変更](/docs/ja-jp/manage-users/cookies/samesite-cookie-attribute-changes)
* [Cookie を使用したシングルページアプリケーションの認証](/docs/ja-jp/manage-users/cookies/spa-authenticate-with-cookies)