セッション

セッションとは、特定の期間におけるユーザーおよびアプリケーション間の一連のインタラクションです。1つのセッションは複数のアクティビティ（ページビュー、イベント、ソーシャル インタラクション、eコマーストランザクションなど）で構成され、ユーザーが接続している間、この情報は一時的に保存できます。

標準のSet-Cookieヘッダー実装では、ユーザーがWebサイトを離れるかブラウザーを閉じるとセッションが終了します。ユーザーが毎回ログインしなくても済むように、アプリケーションはセッションCookieの最大有効期間を設定することでセッションを延長できます。ユーザーがログアウトするか、セッション有効期間の制限に達すると、セッションは終了します。

詳細については、Auth0のプライバシーおよびCookieポリシーを確認してください。

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

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

認証を要求するアプリケーションの構築では、要求が発生するたびにユーザーが認証されているかどうかを判断するために、セッションを使用することができます。アプリの構築方法に応じて、さまざまな認証フローが推奨されユーザーにとってより安全なエクスペリエンスをサポートします。

たとえば、storezero.ioというOIDC準拠（OpenID Connect）のWebサイトを考えてみましょう。

Example e-commerce website Storezero.io

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

以下にリストされているユースケースでは、ユーザーがチェックアウトする前に以前の注文を確認したいシナリオを考えてみましょう。そのためには、［My Account（マイアカウント）］セクションの［All Orders（すべての注文）］ページに移動し、ログインするように求められます。

ログインフロー

大部分のアプリケーションタイプ（Webアプリ、シングルページアプリ、ネイティブアプリなど）では、PKCEを使用した認可コードフローを使用してログイン認証を容易にする必要があります。このフローでは、認可コードをトークンと交換します。

ユーザーはユーザー名とパスワードを使用してログインします

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

  1. Auth0のSDKはローカル セッションを作成し、ユーザーをAuth0認可サーバー（/authorizeエンドポイント）にリダイレクトします。

  2. 認可サーバーはセッションを作成し、ユーザーをログインおよび認可プロンプトにリダイレクトします。

  3. ユーザーはユーザー名とパスワードを使用して認証します。

  4. Auth0認可サーバーは、ユーザーが以前に作成したセッションを更新して、ログインしていることを示します。

  5. 使用されるフローに応じて、認可サーバーはIDトークンまたは認可コードのいずれかとともにユーザーをアプリケーションに返します。

  6. アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。

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

  • 1つ目は、ローカルセッション（storezero.io）で、ユーザーが認証されているかどうかをアプリケーションに示します。

  • 2つ目は認可サーバーセッション（storezero.auth0.com）で、ユーザーが認証されているかどうかをサーバーに示します。サーバーセッションは、オプションで認証の詳細を追跡することもできます。

    • たとえば認可サーバーは、ユーザーが多要素認証（MFA）を活用したかどうかを追跡できます。この情報を使用して、ユーザーが次に認可サーバーにアクセスしたときに、ログインまたはMFAの使用を求めるかどうかを判断できます。

ユーザーがIDプロバイダーを使用してログインする

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

  1. Auth0のSDKはローカル セッションを作成し、ユーザーをAuth0認可サーバー（/authorizeエンドポイント）にリダイレクトします。

  2. 認可サーバーはセッションを作成し、ユーザーをログインおよび認可プロンプトにリダイレクトします。

  3. Facebookでログインすることを選択すると、認可サーバーはユーザーをFacebookにリダイレクトします。

  4. Facebookはセッションを作成し、ユーザーを認証します。次に、 Facebookはセッションを更新して、ユーザーがログインしていることを示します。

  5. FacebookはユーザーをAuth0認可サーバーに返します。認可サーバーはセッションを更新して、ユーザーがログインしていることを示します。

  6. 使用されるフローに応じて、認可サーバーはIDトークンまたは認可コードのいずれかとともにユーザーをアプリケーションに返します。

  7. アプリケーションはトークンまたは認可コードをアクセストークンと交換し、フローを完了します。

このシナリオでは、ローカルセッション（storezero.io）、認可サーバーセッション（storezero.auth0.com）、およびIDプロバイダー（IdP）セッション（facebook.com）の3つのセッションが作成されます。

Facebookのサーバー上のIdPセッションはユーザーを認証し、シームレスなSSOエクスペリエンスを提供します。ユーザーはすでにFacebookにログインしている可能性が高いため、多くの場合、ユーザーは手動でFacebook認証情報を提供しなくても認証されます。

SPAのセッション管理

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

ただし、シングルページアプリ（SPA）などのバックエンドのないアプリケーションでは、ローカルセッションは使用できません。代わりにこれらのアプリケーションは、サイレント認証と呼ばれるアプローチを使用して、ユーザーのログイン状態を維持します。

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

  • 認可サーバー上のセッションが期限切れになっていない場合は、トランザクションはシームレスに続行されます。サーバーは、postMessageを活用するWMRM（Webメッセージ応答モード）を介してアクセストークンを送信します。

  • 認可のセッションが期限切れになっているか、ユーザーがログアウトした場合、iframe内のリダイレクトはエラーを返します。その後、アプリケーションはユーザーを認可サーバーに誘導して再認証を行う必要があります。

もっと詳しく