セッション

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

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

Auth0 は、アプリケーションを通じて認証されたすべてのユーザーについて、ログインセッションを維持します。ユーザーが新たに標準のログインを行うと、Auth0 はそのログインセッションをリセットします。また、パスワード、メールアドレス、電話番号、またはユーザー名を更新すると、そのユーザーの Auth0 セッションも期限切れになります。認証が必要なアプリケーションを構築する場合、リクエストが発生するたびにユーザーが認証済みかどうかを判断するために、セッションを利用できます。アプリの構築方法によっては、ユーザーにより安全な体験を提供するために、異なるが推奨されます。たとえば、storezero.io という OIDC 準拠の ( Connect) Web サイトを考えてみましょう。

Storezero.io では、購入を完了するためにユーザーがログインする必要はありません。ただし、サイトの My Account セクションを表示するには、ユーザーはログインする必要があります。以下に挙げるユースケースでは、ユーザーが購入手続きに進む前に過去の注文を確認したい状況を考えてみましょう。そのためには、My Account セクションの All Orders ページに移動し、ログインを求められます。ほとんどの種類のアプリケーション (web app、シングルページアプリケーション、ネイティブアプリなど) では、ログイン認証を行うために PKCE を使用した Authorization Code フローを使用すべきです。このフローでは、認可コードをトークンと交換します。

PKCE を使用した Authorization Code フローは、バックエンドを持たないシングルページアプリケーションで従来使われていた implicit flow に代わるものです。最適なセキュリティを確保するため、新規開発ではこのフローを使用する必要があります。また、implicit flow を使用している既存のアプリケーションを、PKCE で保護された認可コードフローへ移行することも強く推奨されます。

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

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

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

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

ローカルセッション (storezero.io) 。これは、ユーザーが認証済みかどうかをアプリケーションに示します。
セッション (storezero.auth0.com) 。これは、ユーザーが認証済みかどうかをサーバーに示します。サーバーセッションでは、認証に関する詳細を任意で追跡することもできます。
- たとえば、認可サーバーは、ユーザーが多要素認証 (MFA) を利用したかどうかを追跡できます。こうした情報は、ユーザーが次に認可サーバーにアクセスしたときに、ログインを求めるべきか、多要素認証を求めるべきかを判断するために使用できます。

ユーザーがアイデンティティプロバイダーでログインする

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

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

このシナリオでは、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 内のリダイレクトはエラーを返します。その場合、アプリケーションは再認証のためにユーザーを認可サーバーへ誘導する必要があります。

ユーザーを管理

アクセスを管理する