> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> AllowList に追加されていない URL にユーザーをリダイレクトする方法を説明します。

# ユーザーをリダイレクトする

<Tooltip tip="ID Token: リソースへのアクセスではなく、クライアント自身のための認証情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=ID+Tokens">ID Tokens</Tooltip> (認証) を検証した後、アプリケーション内の特定のページ (URL) にユーザーをリダイレクトできます。動作例については、[React: Login Quickstart](/docs/ja-jp/quickstart/spa/react) をお試しください。

<div id="redirect-users-to-callback-urls-on-the-allowlist">
  ## AllowList 上のコールバック URL にユーザーをリダイレクトする
</div>

コールバック URL は権限のない第三者によって改ざんされる可能性があるため、Auth0 では、[Application's Settings](https://manage.auth0.com/#/applications/\{yourClientId}/settings) の **Allowed Callback URLs** フィールドで設定された AllowList 上の URL のみを有効なものとして認識します。ユーザーを AllowList 上のコールバック URL に戻すには、その後どこへ進めるかをアプリケーション側で把握しておく必要があります。

これを行う方法は 2 つあります。

* Cookie とブラウザーセッションを使用する
* `state` パラメータを使用する

ユーザーの認証中は、`redirect_uri` リクエストパラメータがコールバック URL として使用されます。ここでアプリケーションは Auth0 からのレスポンスを受け取り、処理します。また、多くの場合、認証完了後にユーザーがリダイレクトされる URL でもあります。`redirect_uri` の動作について詳しくは、[OAuth 2.0 Authorization Framework](/docs/ja-jp/authenticate/protocols/oauth) を参照してください。

<Tabs>
  <Tab title="Cookie またはブラウザーセッション">
    Cookie またはブラウザーセッションを使用して、戻り先 URL を保存できます。これは実装しやすいシンプルな方法ですが、Cookie が保持されない場合には問題が発生することがあります。この場合、2 つの別個のユーザーセッションが開始されます。それぞれ役割が異なるため、望ましいユーザー体験を実現するには考慮が必要です。

    * **Auth0-provided SSO Session**: Auth0 は、ユーザーが資格情報の入力を複数回求められずに認証セッションを維持できるように、[Single Sign On (SSO)](/docs/ja-jp/authenticate/single-sign-on) のためのセッションを提供します。このセッションは Auth0 によって維持され、テナントのドメイン (または `CNAME`) に紐付いた Cookie として参照されます。Auth0 セッションの長さを決定する [tenant settings](/docs/ja-jp/manage-users/sessions/configure-session-lifetime-settings) は 2 つあります。

      * `idle_session_lifetime` は、操作がない状態でもセッションが維持される期間です。
      * `session_lifetime` は、セッションを維持できる最大期間です。

      これらの設定は、テナント内のすべてのアプリケーションに適用されるため、ユースケースに合ったセキュリティモデルに合わせて設定する必要があります。
    * **Application Session**: アプリケーション側でも、独自のセッションの考え方を持つ必要があります。ユーザーセッション中、アプリケーションは追加のトークンを要求したり、有効期限切れのトークンを更新したりする必要が生じることがあります。これらのトークンはアプリケーション内に保存し、安全な Cookie を使ってブラウザーに返される識別子を用いて参照する必要があります。

    ユーザーが Auth0 で認証された後、そのセッションをどれだけ保持するかはアプリケーション側で決定します。
  </Tab>

  <Tab title="State パラメータ">
    別の方法として、`state` パラメータを使ってディープリンクを作成し、コールバック側でそれを解釈して転送先のパスを判断することもできます。この方法は実装に少し手間がかかりますが、リダイレクト完了後にアプリケーションが必要な情報を確実に取得できます。詳しくは、[Prevent Attacks and Redirect Users with OAuth0 2.0 State Parameters](/docs/ja-jp/secure/attack-protection/state-parameters) を参照してください。

    この方法では、認証リクエストの開始時にランダムな値を送信し、レスポンスの処理時に受信した値を検証します (つまり、検証を行えるようにするための情報を、クライアントアプリケーション側のセッションや別の保存先に保持しておく必要があります) 。一致しない state を含むレスポンスを受け取った場合、攻撃の標的になっていた可能性が高いといえます。これは、送信していないリクエストに対するレスポンスであるか、誰かが正当なレスポンスを偽装しようとしている可能性があるためです。

    レスポンスの検証に必要なデータをどこに保持するのが最適かは、アプリケーションの種類によって異なります。たとえば、プログレッシブウェブアプリが SPA フレームワークを利用している場合はローカルストレージに保存できますし、従来型のウェブアプリフレームワークであればサーバー側セッションに保存します。
  </Tab>
</Tabs>

<div id="redirect-users-to-other-urls">
  ## ユーザーを他のURLにリダイレクトする
</div>

認証後にユーザーのリダイレクト先が、必ずしもコールバックURLになるとは限りません。たとえば、ユーザーがアプリケーション内の保護されたページにアクセスしようとして、その操作をきっかけに認証リクエストが開始される場合は、認証完了後にユーザーを本来アクセスしたかったページへ戻せるよう、そのURLを保存しておくことができます。リダイレクト先のURLは、次の方法で保存できます。

* [state パラメータでユーザーをリダイレクトする](/docs/ja-jp/secure/attack-protection/state-parameters)
* [ルール内からユーザーをリダイレクトする](/docs/ja-jp/customize/rules/redirect-users)

アプリケーションの種類と、使用している[フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)の種類に最も適した方法を選択してください。保存したURLを取得し、ユーザーを目的の場所へリダイレクトするために必要なロジックをアプリケーションに実装してください。[Auth0 SDKs](/docs/ja-jp/libraries) でも、リダイレクトURLがサポートされています。

<div id="learn-more">
  ## さらに詳しく
</div>

* [代替Logoutでユーザーをリダイレクトする](/docs/ja-jp/authenticate/login/logout/redirect-users-after-logout)
* [プログレッシブプロファイリングの仕組みを理解する](/docs/ja-jp/manage-users/user-accounts/user-profiles/progressive-profiling)