パートナー向けリダイレクトアクション
ユーザーのログインまたはサインアップ時にリダイレクトアクションを使用すると、ユーザーは外部のページ（同意フォームなど）に一度リダイレクトされてから、Auth0に戻ってログインやサインアップの手続きを済ませることができます。ユーザーを外部のアプリケーションにリダイレクトし、以下のようなアクションを実行するように促すことができます。
アクションを起こす（IDプルーフィングなど）
情報を提供する（プログレッシブプロファイリング）
何かに同意する（同意書やサービス規約など）
以下のプロセスがリダイレクトアクションで起こります。
顧客アプリケーションは、ユーザーをAuth0にリダイレクトしてログインさせます。
ログインが成功すると、Post Loginトリガー内のすべてのアクションが実行されます（MFAが有効な場合は、MFAの前に実行されます）。
アクションがリダイレクトをトリガーすると、ユーザーは指定されたURLに状態パラメーターと共に送信されます。このURLは、お使いのサービスまたは顧客によってホストされていなければなりません。
ユーザーは、元の状態値と共に、特定のパスでAuth0にリダイレクトまたはPOSTされ、その後、Actionが
onContinuePostLoginに存在するコードを実行します。ユーザーは、自身のIDと共にアプリケーションに戻されるか、何かが失敗した場合はエラーメッセージが表示されます。
サービスをプロセスに紐づける準備ができたら、以下の重要な要素を検討してください。
Auth0からリダイレクトするタイミングについて、どのように判断するのか?
ユーザーのapp_metadataでフラグを立てるのか?
クライアント側の特定のメタデータフィールドに基づくのか?
検証すべき既存のユーザープロファイルデータをどのように処理するのか?（このデータはユーザーが提供したものか、Google、Facebook、Microsoft Entra IDなどフェデレーションIDソースからのものである可能性があります。）
ご利用のサービスでAuth0からどのようなデータが必要で、どうやって安全に取得するのか?
ご利用のサービスでAuth0からどのように状態値を永続化するのか?
POST/リダイレクトしたい
/continueURLをどのように取得・永続化するのか?Auth0に何を返却し、これをどうやって安全に実行するのか?
IDプルーフィングが完了し、成功した状態であることをどのように示すか?
レート制限に注意し、必要なときだけ更新する
カスタムトークンクレームを使って、要求側アプリケーションに情報をどのように戻すのか?
これらすべての質問等に対する回答については、「アクションを使ってリダイレクトする」をお読みください。アクション統合を送信する準備ができたら、「パートナー向けアクション統合