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

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

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

ユーザーのIDトークンを検証（認証）したら、アプリケーション内でユーザーを特定のページ（URL）に戻すことができます。動作する仕組みの例については、「[React：ログインのクイックスタート](/docs/ja-jp/quickstart/spa/react)」を参照してください。

## AllowListにあるCallback URLにユーザーをリダイレクトする

Callback URLは認可されていない第三者によって操作される可能性があるため、Auth0は[アプリケーションの設定](https://manage.auth0.com/#/applications/\{yourClientId}/settings)で **［Allowed Callback URLs（許可されているCallback URL）］** フィールドのAllowListに含まれるURLのみを有効だと認めます。AllowListにあるCallback URLにユーザーを戻すには、ユーザーがどのようにすれば先に進み続けられるかをアプリケーションが理解しなければなりません。

これを行うには次の2つの方法があります。

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

ユーザーの認証では、要求内の`redirect_uri`パラメーターがCallback URLとして使用されます。これは、アプリケーションがAuth0からの応答を受け取って処理する場所で、大抵の場合には認証後にユーザーをリダイレクトするURLになります。`redirect_uri`が動作する仕組みについては、「[OAuth 2.0の認可フレームワーク](/docs/ja-jp/authenticate/protocols/oauth)」を参照してください。

<Tabs>
  <Tab title="クッキーまたはブラウザーセッション">
    リターンURLの値を保存するために、クッキーやブラウザーセッションを使用することができます。この方法は簡単ですが、クッキーが保持されていない場合は問題が起きる可能性があります。この状況では、2つの別々のユーザーセッションが開始されます。それぞれの目的は異なっており、希望するユーザーエクスペリエンスを実現するために注意が必要です。

    * **Auth0提供のSSOセッション** ：Auth0は、[シングルサインオン（SSO）](/docs/ja-jp/authenticate/single-sign-on)を有効にするためのセッションを提供しており、ユーザーが一度だけ資格情報を入力すれば、認証セッションを維持できるようにします。このセッションは、Auth0によって維持され、テナントドメイン（または`CNAME`）に関連付けられたクッキーバウンドとして参照されます。Auth0セッションの長さを決定する[テナント設定](/docs/ja-jp/manage-users/sessions/configure-session-lifetime-settings)は2つあります。

      * `idle_session_lifetime`は、ユーザーが操作しない状態でセッションがどれだけ長く保持されるかを示します。
      * `session_lifetime`は、セッションが保持される最長期間です。

      これらの設定は、テナント内のすべてのアプリケーションに適用され、ユースケースに一致するセキュリティモデルに適合している必要があります。
    * **アプリケーションセッション** ：アプリケーションにはセッションのコンセプトも含む必要があります。ユーザーセッションを通して、アプリケーションは追加トークンの要求、または有効期限切れトークンの更新をする必要があるかもしれません。これらのトークンをアプリケーション内に保存し、セキュアクッキーを使用してブラウザーに返されたIDで参照する必要があります。

    ユーザーがAuth0で認証したら、このセッションがどれだけ保持されるかはアプリケーションによります。
  </Tab>

  <Tab title="状態パラメーター">
    別の方法として、`state`パラメーターを使用してディープリンクを作成し、コールバックで解釈し、転送先のパスを決定できます。この方法は、実装に多少の時間がかかりますが、リダイレクトが完了した際に、アプリケーションが必要な情報を確実に保有しているようにします。詳細ついては、「[OAuth0 2.0の状態パラメーターを使って攻撃を防ぎ、ユーザーをリダイレクトする](/docs/ja-jp/secure/attack-protection/state-parameters)」をお読みください。

    この方法を使用すると、認証要求を開始する際にランダムな値を送り、応答を処理する際に受け取った値を検証します（これはクライアントアプリケーション側でセッションや他の媒体に検証を行うための情報を保存しておくことを意味します）。状態が一致しない応答を受け取る場合は、受信者側が望んでいない要求に対する応答か、真の応答を偽造しようとしていることになるため、攻撃の標的になっているかもしれないと推測することができます。

    アプリケーションタイプは、アプリの応答検証を許可するデータを保存する最適な場所を決定します。たとえば、進行中のウェブアプリがSPAフレームワークを利用している場合、ローカルストレージにこの情報を保存することができます。一方、従来のWebアプリフレームワークでは、サーバー側のセッションに保存することになります。
  </Tab>
</Tabs>

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

認証後にユーザーを送りたいリダイレクト先が必ずしもCallback URLだとは限りません。たとえば、アプリケーションでユーザーが保護されたページにアクセスしようとして、その操作が認証要求のトリガーとなった場合には、そのURLを保管し、認証の完了後にユーザーをその意図したページにリダイレクトで戻すことができます。以下の方法で、使用したいURLを保管します。

* [状態パラメーターでユーザーをリダイレクトする](/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 SDK](/docs/ja-jp/libraries)にも、リダイレクトURLへの対応が含まれています。

## もっと詳しく

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