> ## 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="セッションクッキー: これが存在すると、ユーザーは認証済みと見なされます。" cta="用語集を表示" href="/ja/docs/glossary?term=session+cookie">セッションクッキー</Tooltip> の最大有効期間を設定して、セッションを延長できます。セッションは、ユーザーがログアウトしたとき、またはセッションの有効期間の上限に達したときに終了します。

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

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

Auth0 は、アプリケーションを通じて認証されたすべてのユーザーのログインセッションを維持します。ユーザーが新たに通常のログインを行うと、Auth0 はログインセッションをリセットします。パスワード、メールアドレス、電話番号、またはユーザー名を更新した場合も、ユーザーの Auth0 セッションは失効します。

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

たとえば、storezero.io という OIDC 準拠の (<Tooltip tip="OpenID: アプリケーションがログイン情報を収集および保存せずにユーザーの本人確認を行えるようにする認証のオープン標準。" cta="用語集を表示" href="/ja/docs/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 アプリ、シングルページアプリケーション、ネイティブアプリなど) では、ログイン時の認証に [PKCE を使用する認可コードフロー](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) を使用する必要があります。このフローでは、認可コードをトークンに交換します。

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

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

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

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

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

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

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

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

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

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

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

Facebook サーバー上の IdP セッションはユーザーを認証し、シームレスな <Tooltip tip="シングルサインオン（SSO）: ユーザーが 1 つのアプリケーションにログインすると、他のアプリケーションにも自動的にログインできるようにするサービス。" cta="用語集を見る" href="/ja/docs/glossary?term=SSO">SSO</Tooltip> を実現します。ユーザーはすでに Facebook にログインしている可能性が高いため、多くの場合、Facebook の認証情報を手動で入力しなくても認証されます。

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

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

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

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

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

<div id="learn-more">
  ## 詳細
</div>

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