> ## 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トークン: リソースへのアクセスではなく、クライアント自体を対象とした認証情報です。" cta="用語集を見る" href="/ja/docs/glossary?term=ID+Tokens">IDトークン</Tooltip> を検証した後、アプリケーション内の特定のページ (URL) にユーザーを戻すことができます。動作例については、[React: Login Quickstart](/ja/docs/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](/ja/docs/authenticate/protocols/oauth) を参照してください。

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

    * **Auth0-provided SSO Session**: Auth0 は、ユーザーが複数回認証情報の入力を求められずに認証セッションを維持できるよう、[Single Sign On (SSO)](/ja/docs/authenticate/single-sign-on) を有効にするためのセッションを提供します。このセッションは Auth0 によって維持され、テナントのドメイン (または `CNAME`) に紐付いた Cookie として参照されます。Auth0 セッションの長さを決定する [テナント設定](/ja/docs/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](/ja/docs/secure/attack-protection/state-parameters) を参照してください。

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

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

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

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

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

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

<div id="learn-more">
  ## 詳細
</div>

* [別のログアウト方法を使用してユーザーをリダイレクトする](/ja/docs/authenticate/login/logout/redirect-users-after-logout)
* [段階的プロファイリングの仕組みを理解する](/ja/docs/manage-users/user-accounts/user-profiles/progressive-profiling)