セッションのユースケース
Auth0は、アプリケーションを通じて認証するすべてのユーザーのログインセッションを維持します。ユーザーが新しい標準ログインを実行すると、Auth0はログインセッションをリセットします。パスワード、メール、電話番号を更新すると、ユーザーのAuth0セッションも期限切れになります。 認証を要求するアプリケーションの構築では、要求が発生するたびにユーザーが認証されているかどうかを判断するために、セッションを使用することができます。アプリの構築方法に応じて、さまざまな認証フローが推奨されユーザーにとってより安全なエクスペリエンスをサポートします。 たとえば、storezero.ioというOIDC準拠（ Connect）のWebサイトを考えてみましょう。
ログインフロー
大部分のアプリケーションタイプ（Webアプリ、シングルページアプリ、ネイティブアプリなど）では、PKCEを使用した認可コードフローを使用してログイン認証を容易にする必要があります。このフローでは、認可コードをトークンと交換します。PKCEを使った認可コードフローは、以前にバックエンドのないシングルページアプリで使用していた暗黙フローに取って代わるものです。新しい開発では、最適なセキュリティを確保するために、このフローを使用しなければなりません。暗黙フローを使用している既存のアプリは、PKCEで強化された認可コードフローに移行することを強くお勧めします。
ユーザーはユーザー名とパスワードを使用してログインします
この例では、ユーザーはユーザー名とパスワードを使用して手動でログインします。- Auth0のSDKはローカル セッションを作成し、ユーザーをAuth0認可サーバー（
/authorizeエンドポイント）にリダイレクトします。 - 認可サーバーはセッションを作成し、ユーザーをログインおよび認可プロンプトにリダイレクトします。
- ユーザーはユーザー名とパスワードを使用して認証します。
- Auth0認可サーバーは、ユーザーが以前に作成したセッションを更新して、ログインしていることを示します。
- 使用されるフローに応じて、認可サーバーはIDトークンまたは認可コードのいずれかとともにユーザーをアプリケーションに返します。
- アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。
- 1つ目は、ローカルセッション （storezero.io）で、ユーザーが認証されているかどうかをアプリケーションに示します。
-
2つ目は認可サーバーセッション （storezero.auth0.com）で、ユーザーが認証されているかどうかをサーバーに示します。サーバーセッションは、オプションで認証の詳細を追跡することもできます。
- たとえば認可サーバーは、ユーザーが多要素認証（MFA）を活用したかどうかを追跡できます。この情報を使用して、ユーザーが次に認可サーバーにアクセスしたときに、ログインまたはMFAの使用を求めるかどうかを判断できます。
ユーザーがIDプロバイダーを使用してログインする
この例では、ユーザーはユーザー名とパスワードの代わりにFacebookでログインすることを選択します。- Auth0のSDKはローカル セッションを作成し、ユーザーをAuth0認可サーバー（
/authorizeエンドポイント）にリダイレクトします。 - 認可サーバーはセッションを作成し、ユーザーをログインおよび認可プロンプトにリダイレクトします。
- Facebookでログインすることを選択すると、認可サーバーはユーザーをFacebookにリダイレクトします。
- Facebookはセッションを作成し、ユーザーを認証します。次に、 Facebookはセッションを更新して、ユーザーがログインしていることを示します。
- FacebookはユーザーをAuth0認可サーバーに返します。認可サーバーはセッションを更新して、ユーザーがログインしていることを示します。
- 使用されるフローに応じて、認可サーバーはIDトークンまたは認可コードのいずれかとともにユーザーをアプリケーションに返します。
- アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。
SPAのセッション管理
前の例では、ユーザーがいずれかのログインフローを開始すると、ローカルセッションが作成されます。このローカルセッションは、ユーザーのログイン状態を維持し、再認証が必要になるタイミングを決定できます。 ただし、シングルページアプリ（SPA）などのバックエンドのないアプリケーションでは、ローカルセッションは使用できません。代わりにこれらのアプリケーションは、サイレント認証と呼ばれるアプローチを使用して、ユーザーのログイン状態を維持します。 サイレント認証では、認可サーバー上のセッションを使用して、ユーザーが再認証する必要があるタイミングを判断します。非表示のiframeは、prompt=noneパラメーターとともに認証要求を認可サーバーにリダイレクトします。このパラメータにより、サーバーはユーザーに入力を求めなくなります。
- 認可サーバー上のセッションが期限切れになっていない場合は、トランザクションはシームレスに続行されます。サーバーは、
postMessageを活用するWMRM（Webメッセージ応答モード）を介してアクセストークンを送信します。 - 認可のセッションが期限切れになっているか、ユーザーがログアウトした場合、iframe内のリダイレクトはエラーを返します。その後、アプリケーションはユーザーを認可サーバーに誘導して再認証を行う必要があります。