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

# セッションのユースケース

> アプリケーションの種類や関係する認可フローに応じて、セッションを使用してユーザーが認証済みかどうかを判断するさまざまな方法を紹介します。

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

認証が必要なアプリケーションを構築する場合、リクエストのたびにセッションを使用して、ユーザーが認証済みかどうかを判断できます。ユーザーにより安全な体験を提供するための推奨認可フロー (認可フロー：OAuth 2.0フレームワークで規定されている認可グラント（またはワークフロー）。)は、アプリの構築方法によって異なります。

たとえば、storezero.ioというOIDC (OpenID (OpenID：ログイン情報を収集・保存することなく、アプリケーションがユーザーの身元を検証できるようにする認証のオープン標準。) Connect) 準拠のWebサイトについて考えてみましょう。

![eコマースWebサイトの例：Storezero.io](https://mintlify.s3.us-west-1.amazonaws.com/auth0/docs/images/cdy7uua7fh8z/5XXxdX4fuApQtAapQfZU1b/2fd9161af60962e3de3fc951d95b83d1/use-case-storezero.png)

Storezero.ioでは、ログインしなくても購入を完了できます。ただし、サイトの［My Account］セクションを表示するにはログインが必要です。

以下のユースケースでは、ユーザーがチェックアウト前に過去の注文を確認しようとするシナリオを想定します。ユーザーは［My Account］セクションの［All Orders］ページに移動し、そこでログインを求められます。

## ログインフロー

ほとんどの種類のアプリケーション (Webアプリ、シングルページアプリ、ネイティブアプリなど) では、ログイン認証に[PKCEを使用した認可コードフロー](https://auth0.com/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce.md)を使用してください。このフローでは、認可コードをトークンと交換します。

PKCEを使用した認可コードフローは、バックエンドを持たないシングルページアプリで従来使用されていたインプリシットフローに代わるものです。最適なセキュリティを確保するため、新規開発では必ずこのフローを使用してください。また、インプリシットフローを使用している既存のアプリについても、PKCEで強化された認可コードフローへの移行を強く推奨します。

### ユーザーがユーザー名とパスワードでログインする

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

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

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

* **ローカルセッション** (storezero.io) ：ユーザーが認証済みかどうかをアプリケーションに示します。
* **認可サーバー (認可サーバー：ユーザーのアクセス範囲の定義に寄与する集中型サーバーです。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。)セッション** (storezero.auth0.com) ：ユーザーが認証済みかどうかをサーバーに示します。また、サーバーセッションでは、必要に応じて認証に関する詳細を追跡することもできます。

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

### ユーザーがIDプロバイダーでログインする

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

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

このシナリオでは、**ローカルセッション** (storezero.io) 、**認可サーバーセッション** (storezero.auth0.com) 、**IDプロバイダー (IDプロバイダー（IdP）：デジタルIDを保存・管理するサービス。) (IdP) セッション** (facebook.com) の3つのセッションが作成されます。

FacebookのサーバーにあるIdPセッションはユーザーを認証し、シームレスなSSO (シングルサインオン（SSO）：ユーザーが1つのアプリケーションにログインすると、他のアプリケーションにも自動的にログインさせるサービス。)体験を実現します。ユーザーはすでにFacebookにログインしていることが多いため、Facebookの資格情報を手入力しなくても認証が完了するケースがよくあります。

## SPAのセッション管理

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

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

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

* 認可サーバー上のセッションが有効期限内であれば、取引はシームレスに続行されます。サーバーは、`postMessage`を利用するWMRM (Web Message Response Mode) を通じてアクセストークン (アクセストークン：APIへのアクセスに使用される、不透明な文字列またはJWT形式の認可クレデンシャル。)を送信します。
* 認可サーバー上のセッションが期限切れになっている場合や、ユーザーがログアウトした場合は、iframe内のリダイレクトがエラーを返します。この場合、アプリケーションはユーザーを認可サーバーに誘導し、再認証させる必要があります。