Skip to main content
Auth0は、アプリケーションを通じて認証したすべてのユーザーのログインセッションを維持します。ユーザーが新たに標準のログインを行うと、Auth0はログインセッションをリセットします。また、パスワード、メールアドレス、電話番号、ユーザー名のいずれかを更新した場合も、そのユーザーのAuth0セッションは期限切れになります。 認証が必要なアプリケーションを構築する場合、リクエストのたびにセッションを使用して、ユーザーが認証済みかどうかを判断できます。ユーザーにより安全な体験を提供するための推奨は、アプリの構築方法によって異なります。 たとえば、storezero.ioというOIDC ( Connect) 準拠のWebサイトについて考えてみましょう。
eコマースWebサイトの例：Storezero.io
Storezero.ioでは、ログインしなくても購入を完了できます。ただし、サイトの［My Account］セクションを表示するにはログインが必要です。 以下のユースケースでは、ユーザーがチェックアウト前に過去の注文を確認しようとするシナリオを想定します。ユーザーは［My Account］セクションの［All Orders］ページに移動し、そこでログインを求められます。

​
ログインフロー

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

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

この例では、ユーザーがユーザー名とパスワードを入力して手動でログインします。
  1. Auth0のSDKがローカルセッションを作成し、ユーザーをAuth0の認可サーバー (/authorizeエンドポイント) にリダイレクトします。
  2. 認可サーバーがセッションを作成し、ユーザーをログインおよび認可のプロンプトにリダイレクトします。
  3. ユーザーがユーザー名とパスワードで認証します。
  4. Auth0の認可サーバーは、先ほど作成したユーザーのセッションを更新し、ユーザーがログイン済みであることを記録します。
  5. 使用するフローに応じて、認可サーバーはIDトークンまたは認可コードを付けて、ユーザーをアプリケーションに戻します。
  6. アプリケーションがトークンまたは認可コードをアクセストークンと交換し、フローが完了します。
このフローでは、2つのセッションが作成されます。
  • ローカルセッション (storezero.io) ：ユーザーが認証済みかどうかをアプリケーションに示します。
  • セッション (storezero.auth0.com) ：ユーザーが認証済みかどうかをサーバーに示します。また、サーバーセッションでは、必要に応じて認証に関する詳細を追跡することもできます。
    • たとえば、認可サーバーはユーザーが多要素認証 (MFA) を利用したかどうかを追跡できます。この情報をもとに、ユーザーが次回認可サーバーにアクセスした際に、ログインや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) 、 (IdP) セッション (facebook.com) の3つのセッションが作成されます。 FacebookのサーバーにあるIdPセッションはユーザーを認証し、シームレスな体験を実現します。ユーザーはすでにFacebookにログインしていることが多いため、Facebookの資格情報を手入力しなくても認証が完了するケースがよくあります。

​
SPAのセッション管理

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