Skip to main content
ユーザーがログインまたはサインアップするとき、リダイレクト Action を使うと、ユーザーを外部ページ (同意フォームなど) にリダイレクトし、その後 Auth0 に戻してログインまたはサインアップを完了させることができます。ユーザーを外部アプリケーションにリダイレクトして、次のような操作を求めることができます。
  • ID 証明などのアクションを実行する
  • プログレッシブプロファイリングなどの情報を入力する
  • 同意や利用規約などに同意する
Post Login トリガーでのリダイレクト Action の図: Customer Application はユーザーを Auth0 にリダイレクトしてログインさせます。ログインが成功すると、Post Login トリガー内のすべての Actions が実行されます（MFA が有効な場合は、その前に実行されます）。Action がリダイレクトをトリガーすると、ユーザーは state パラメーターとともに指定された URL に送られます。この URL は、あなたのサービスまたは顧客がホストしている必要があります。ユーザーは元の state 値とともに、そのドメイン上の特定のパスで Auth0 にリダイレクトまたは POST で戻され、Action は onContinuePostLogin にあるコードを実行します。最後に、ユーザーは自身の ID 情報とともにアプリケーションに戻されるか、問題が発生した場合はエラーメッセージが返されます。
このプロセスは、リダイレクト Action で次のように行われます。
  1. Customer Application がユーザーを Auth0 にリダイレクトしてログインさせます。
  2. ログインが成功すると、Post Login trigger 内のすべての Actions が実行されます (MFA が有効な場合は、その前に実行されます) 。
  3. Action がリダイレクトをトリガーすると、ユーザーは state パラメーターとともに指定された URL に送られます。この URL は、あなたのサービスまたは顧客がホストしている必要があります。
  4. ユーザーは元の state 値とともに、そのドメイン上の特定のパスで Auth0 にリダイレクトまたは POST で戻され、Action は onContinuePostLogin にあるコードを実行します。
  5. 最後に、ユーザーは自身の ID 情報とともにアプリケーションに戻されるか、問題が発生した場合はエラーメッセージが返されます。
サービスをこのプロセスに組み込む準備ができたら、考慮すべき重要なポイントがいくつかあります。
  • Auth0 の外部にリダイレクトするタイミングをどのように判断しますか？
    • user’s app_metadata のフラグで判断しますか？
    • クライアント上の特定のメタデータフィールドに基づいて判断しますか？
  • 検証が必要な既存のユーザープロファイルデータをどのように扱いますか？ (このデータは、ユーザーが提供したもの、または Google、Facebook、Azure AD などのフェデレーション ID ソースから取得したものです。)
  • サービス側で Auth0 からどのデータが必要で、それをどのように安全に取得しますか？
  • サービス側で Auth0 からの state 値をどのように保持しますか？
  • POST/リダイレクト先となる /continue URL をどのように取得し、保持しますか？
  • Auth0 に何を返し、それをどのように安全に行いますか？
  • ID 証明が完了したことをどのように示し、status をどのように渡しますか？
  • 必要な情報を user’s app_metadata または normalized user profile にどのように保存しますか
  • rate limits に注意し、更新は必要な場合にのみ行ってください
  • custom token claims を使って、requesting application に情報をどのように返しますか？
これらの質問やその他の疑問に答えるには、Redirect with Actions を参照してください。Action Integration を送信する準備ができたら、Action Integrations for Partners. の手順 4〜6 に従ってください。