メインコンテンツへスキップ
セッションとは、一定期間におけるユーザーとアプリケーションの間の一連のやり取りを指します。1 つのセッションには複数のアクティビティ (ページビュー、イベント、ソーシャルでのやり取り、e コマースのトランザクションなど) が含まれる場合があり、ユーザーが接続している間は、その情報を一時的に保存できます。 標準的な Set-Cookie ヘッダーの実装では、ユーザーが Web サイトを離れるか、ブラウザーを閉じると、セッションは終了します。ユーザーが毎回ログインしなくて済むように、アプリケーションでは の最大有効期間を設定して、セッションを延長できます。セッションは、ユーザーがログアウトしたとき、またはセッションの有効期間の上限に達したときに終了します。 詳しくは、Auth0 Privacy and Cookie Policy を参照してください。

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

Auth0 は、アプリケーションを通じて認証されたすべてのユーザーのログインセッションを維持します。ユーザーが新たに通常のログインを行うと、Auth0 はログインセッションをリセットします。パスワード、メールアドレス、電話番号、またはユーザー名を更新した場合も、ユーザーの Auth0 セッションは失効します。 認証が必要なアプリケーションを構築する場合は、リクエストのたびにユーザーが認証済みかどうかを判断するために、セッションを利用できます。アプリの実装方法に応じて、ユーザーにより安全な体験を提供するために、異なる の利用が推奨されます。 たとえば、storezero.io という OIDC 準拠の ( Connect) Web サイトを考えてみましょう。
EC サイト Storezero.io の例
Storezero.io では、購入を完了するためにログインする必要はありません。ただし、サイトの My Account セクションを表示するには、ユーザーはログインする必要があります。 以下のユースケースでは、ユーザーがチェックアウト前に過去の注文を確認したい状況を想定してください。そのため、My Account セクションの All Orders ページに移動すると、ログインを求められます。

​
ログインフロー

ほとんどの種類のアプリケーション (Web アプリ、シングルページアプリケーション、ネイティブアプリなど) では、ログイン時の認証に PKCE を使用する認可コードフロー を使用する必要があります。このフローでは、認可コードをトークンに交換します。
PKCE を使用する認可コードフローは、バックエンドを持たないシングルページアプリケーションで従来使用されていたインプリシットフローに代わるものです。最適なセキュリティを確保するため、新規開発ではこのフローを使用する必要があります。インプリシットフローを使用している既存のアプリを、PKCE を使用する認可コードフローへ移行することも強く推奨されます。

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

この例では、ユーザーは username とパスワードを使って手動でログインします。
  1. Auth0 の SDK がローカルセッションを作成し、ユーザーを Auth0 の認可サーバー (/authorize エンドポイント) にリダイレクトします。
  2. 認可サーバーがセッションを作成し、ユーザーをログインと認可のプロンプトにリダイレクトします。
  3. ユーザーは username とパスワードを使用して認証します。
  4. Auth0 の認可サーバーは、ユーザーがログイン済みであることを示すように、先ほど作成したユーザーのセッションを更新します。
  5. 使用するフローに応じて、認可サーバーは IDトークン または 認可コード のいずれかとともにユーザーをアプリケーションに戻します。
  6. アプリケーションは、トークンまたは認可コードをアクセストークンに交換し、フローを完了します。
このフローでは、2 つのセッションが作成されます。
  • ローカルセッション (storezero.io) 。これは、ユーザーが認証済みかどうかをアプリケーションに示します。
  • セッション (storezero.auth0.com) 。これは、ユーザーが認証済みかどうかをサーバーに示します。サーバーセッションでは、認証に関する詳細を任意で追跡することもできます。
    • たとえば、認可サーバーは、ユーザーが 多要素認証 (MFA) を使用したかどうかを追跡できます。この情報は、ユーザーが次に認可サーバーにアクセスしたときに、ログインを求めるべきか、MFA を求めるべきかを判断するために使用できます。

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

この例では、ユーザーは 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) 、および (IdP) セッション (facebook.com) です。 Facebook サーバー上の IdP セッションはユーザーを認証し、シームレスな を実現します。ユーザーはすでに Facebook にログインしている可能性が高いため、多くの場合、Facebook の認証情報を手動で入力しなくても認証されます。

​
SPA のセッション管理

前述の例では、ユーザーがいずれかのログインフローを開始すると、ローカルセッションが作成されます。このローカルセッションによって、ユーザーのログイン状態を維持し、再認証が必要になるタイミングを判断できます。 ただし、シングルページアプリケーション (SPA) など、バックエンドを持たないアプリケーションではローカルセッションを利用できません。代わりに、こうしたアプリケーションでは、ユーザーのログイン状態を維持するために、サイレント認証 と呼ばれる別の方法を使用します。 サイレント認証では、認可サーバー上のセッションを使用して、ユーザーが再認証を求められるタイミングを判断します。非表示の iframe が、prompt=none パラメーターを付けて認証リクエストを認可サーバーにリダイレクトします。このパラメーターにより、サーバーはユーザーに入力を求めなくなります。
  • 認可サーバー上のセッションがまだ期限切れでなければ、トランザクションはシームレスに続行されます。サーバーは、postMessage を利用する WMRM (Web Message Response Mode) を介して、 を送信します。
  • 認可サーバー上のセッションの有効期限が切れている場合、またはユーザーがログアウトした場合は、iframe 内のリダイレクトによってエラーが返されます。その場合、アプリケーションはユーザーを認可サーバーに誘導して再認証させる必要があります。

​
詳細