メインコンテンツへスキップ
ユーザーのログイン時またはサインアップ時に、Redirect Action を使うと、そのユーザーを外部ページ (同意フォームなど) へリダイレクトし、その後 Auth0 に戻してログインまたはサインアップを完了させることができます。ユーザーを外部アプリケーションにリダイレクトして、次のような対応を求めることもできます。
  • ID 証明などのアクションを実行する
  • プログレッシブプロファイリングなどの情報を提供する
  • 同意や利用規約への同意など、何らかの事項に同意する
Post Login トリガーにおける Redirect Action の図: Customer Application はユーザーを Auth0 にリダイレクトしてログインさせます。ログインに成功すると、Post Login トリガー内のすべての Actions が実行されます(MFA が有効な場合は、その前に実行されます)。Action がリダイレクトをトリガーすると、ユーザーは state パラメーターとともに指定された URL に送られます。この URL は、あなたのサービスまたは顧客がホストしている必要があります。ユーザーは元の state 値とともに、そのドメイン上の特定のパスを通じて Auth0 にリダイレクトまたは POST で戻され、Action は onContinuePostLogin にあるコードを実行します。ユーザーは自身の ID 情報とともにアプリケーションに戻されるか、何らかの問題が発生した場合はエラーメッセージが返されます。
Redirect Action では、このプロセスは次のように進行します。
  1. Customer Application がユーザーを Auth0 にリダイレクトしてログインさせます。
  2. ログインに成功すると、Post Login トリガー内のすべての Actions が実行されます (MFA が有効な場合は、その前に実行されます) 。
  3. Action がリダイレクトをトリガーすると、ユーザーは state パラメーターとともに指定された URL に送られます。この URL は、あなたのサービスまたは顧客がホストしている必要があります。
  4. ユーザーは元の state 値とともに、そのドメイン上の特定のパスを通じて Auth0 にリダイレクトまたは POST で戻され、Action は onContinuePostLogin にあるコードを実行します。
  5. ユーザーは自身の ID 情報とともにアプリケーションに戻されるか、何らかの問題が発生した場合はエラーメッセージが返されます。
サービスをこのプロセスに組み込む準備ができたら、考慮すべき重要な要素がいくつかあります。
  • Auth0 の外部へリダイレクトするタイミングをどのように判断しますか。
    • ユーザーの app_metadata 内のフラグですか。
    • クライアント上の特定のメタデータフィールドに基づきますか。
  • 検証が必要な既存のユーザープロファイルデータをどのように処理しますか。 (このデータは、ユーザーが提供したもの、または Google、Facebook、Azure AD などのフェデレーテッド ID ソースから取得したものである可能性があります。)
  • サービス内で Auth0 から必要となるデータは何で、それをどのように安全に取得しますか。
  • サービス内で Auth0 からの state 値をどのように保持しますか。
  • POST またはリダイレクト先となる /continue URL をどのように取得し、保持しますか。
  • Auth0 に何を返し、それをどのように安全に実現しますか。
  • ID 証明が完了したことと、そのステータスをどのように示しますか。
  • 必要な情報を ユーザーの app_metadata または 正規化されたユーザープロファイル にどのように保存しますか
  • レート制限 に注意し、必要な場合にのみ更新してください
  • カスタムトークンクレーム を使用して、要求元のアプリケーションに情報をどのように返しますか。
こうしたすべての質問などに答えるには、Actions によるリダイレクト を参照してください。Action Integration を送信する準備ができたら、パートナー向け Action Integrations の手順 4〜6 に従ってください。