Skip to main content
(認証) を検証した後、アプリケーション内の特定のページ (URL) にユーザーをリダイレクトできます。動作例については、React: Login Quickstart をお試しください。

​
AllowList 上のコールバック URL にユーザーをリダイレクトする

コールバック URL は権限のない第三者によって改ざんされる可能性があるため、Auth0 では、Application’s Settings の Allowed Callback URLs フィールドで設定された AllowList 上の URL のみを有効なものとして認識します。ユーザーを AllowList 上のコールバック URL に戻すには、その後どこへ進めるかをアプリケーション側で把握しておく必要があります。 これを行う方法は 2 つあります。
  • Cookie とブラウザーセッションを使用する
  • state パラメータを使用する
ユーザーの認証中は、redirect_uri リクエストパラメータがコールバック URL として使用されます。ここでアプリケーションは Auth0 からのレスポンスを受け取り、処理します。また、多くの場合、認証完了後にユーザーがリダイレクトされる URL でもあります。redirect_uri の動作について詳しくは、OAuth 2.0 Authorization Framework を参照してください。
Cookie またはブラウザーセッションを使用して、戻り先 URL を保存できます。これは実装しやすいシンプルな方法ですが、Cookie が保持されない場合には問題が発生することがあります。この場合、2 つの別個のユーザーセッションが開始されます。それぞれ役割が異なるため、望ましいユーザー体験を実現するには考慮が必要です。
  • Auth0-provided SSO Session: Auth0 は、ユーザーが資格情報の入力を複数回求められずに認証セッションを維持できるように、Single Sign On (SSO) のためのセッションを提供します。このセッションは Auth0 によって維持され、テナントのドメイン (または CNAME) に紐付いた Cookie として参照されます。Auth0 セッションの長さを決定する tenant settings は 2 つあります。
    • idle_session_lifetime は、操作がない状態でもセッションが維持される期間です。
    • session_lifetime は、セッションを維持できる最大期間です。
    これらの設定は、テナント内のすべてのアプリケーションに適用されるため、ユースケースに合ったセキュリティモデルに合わせて設定する必要があります。
  • Application Session: アプリケーション側でも、独自のセッションの考え方を持つ必要があります。ユーザーセッション中、アプリケーションは追加のトークンを要求したり、有効期限切れのトークンを更新したりする必要が生じることがあります。これらのトークンはアプリケーション内に保存し、安全な Cookie を使ってブラウザーに返される識別子を用いて参照する必要があります。
ユーザーが Auth0 で認証された後、そのセッションをどれだけ保持するかはアプリケーション側で決定します。

​
ユーザーを他のURLにリダイレクトする

認証後にユーザーのリダイレクト先が、必ずしもコールバックURLになるとは限りません。たとえば、ユーザーがアプリケーション内の保護されたページにアクセスしようとして、その操作をきっかけに認証リクエストが開始される場合は、認証完了後にユーザーを本来アクセスしたかったページへ戻せるよう、そのURLを保存しておくことができます。リダイレクト先のURLは、次の方法で保存できます。 アプリケーションの種類と、使用しているフローの種類に最も適した方法を選択してください。保存したURLを取得し、ユーザーを目的の場所へリダイレクトするために必要なロジックをアプリケーションに実装してください。Auth0 SDKs でも、リダイレクトURLがサポートされています。

​
さらに詳しく