- アプリケーションレベル
- テナントレベル
login_url は、最終的に Auth0 の /authorize エンドポイントにリダイレクトされる、アプリケーション内のルートを指す必要があります。たとえば、https://mycompany.org/login です。https である必要があり、localhost を指定することはできません。login_url には、クエリパラメータや URI フラグメントを含めることができます。
OIDC の Third Party Initiated Login 仕様に従い、Issuer Identifier を含む iss パラメータは、リダイレクト前にクエリ文字列パラメータとして login_url に追加されます。
メタデータプレースホルダーを含む動的ログイン URI
initiate_login_uri にメタデータプレースホルダーを含めるように設定できます。これらのメタデータプレースホルダーは、実行時に動的に置き換えられます。
サポートされるプレースホルダー
| Placeholder | Source | Example |
|---|---|---|
{custom_domain.metadata.KEY} | リクエストで使用されるカスタムドメインのメタデータ | https://{custom_domain.metadata.public_app_host}/login |
{organization.metadata.KEY} | リクエストに関連付けられた組織のメタデータ | https://{organization.metadata.public_login_host}/login |
public_ で始まる必要があります (例: public_app_host) 。リクエストにカスタムドメインと組織コンテキストの両方が含まれている場合は、同じ URI 内で両方の種類のプレースホルダーを組み合わせて使用できます。
検証ルールと制限事項の完全な一覧については、Custom domain URL placeholders を参照してください。
メタデータプレースホルダーは、テナントレベルの
default_redirection_uri ではなく、アプリケーションレベルの initiate_login_uri でのみサポートされます。フォールバック動作
default_redirection_uri にフォールバックします。たとえば、組織が不明な場合や、メタデータキーが存在しない場合です。default_redirection_uri も設定されていない場合、Auth0 はエラーページを表示します。確実なフォールバック先として、テナントレベルの default_redirection_uri を設定することを推奨します。
デフォルトのログインルートをリダイレクトするケース
ユーザーがログインページをブックマークした場合
https://{yourDomain}/authorize に遷移します。すると Auth0 は、次のような URL の https://{yourDomain}/login ページにエンドユーザーをリダイレクトします。
https://{yourDomain}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&...
state パラメーターは、認可トランザクションの状態を追跡する内部データベース内のレコードを参照します。トランザクションが完了すると、または一定時間が経過すると、そのレコードは内部データベースから削除されます。
Organizations を使用していて、エンドユーザーが組織のログインプロンプトをブックマークした場合、Auth0 はユーザーをデフォルトのログインルートにリダイレクトする際に organization パラメーターも含めます。
ユーザーがログインページをブックマークしていて、そのブックマークした /login URL にアクセスすると、トランザクションレコードがすでに存在せず、Auth0 がログインフローを続行できないことがあります。その場合、Auth0 は、設定されていればデフォルトのクライアント URL に、設定されていなければテナントレベルの URL にリダイレクトします。デフォルトのログイン URL が設定されていない場合、Auth0 はエラーページを表示します。
パスワードリセットフローの完了
/post-password-change エンドポイントにより、ユーザーを特定のアプリケーションにリダイレクトできます。client_id が指定され、アプリケーションのログイン URI が設定されている場合、パスワードリセットの完了後にアプリケーションへ戻るためのボタンがユーザーに表示されます。
メールアドレス確認フロー全体
組織メンバーを招待する
https://myapp.com/login に設定されている場合、エンドユーザーに送信される招待メール内のリンクは次のようになります: https://myapp.com/login?invitation={invitation_ticket_id}&organization={organization_id}&organization_name={organization_name}。
そのため、アプリケーション内のルートは、クエリ文字列を通じて invitation パラメーターと organization パラメーターを受け取れる必要があります。招待受諾のトランザクションを開始するには、エンドユーザーを Auth0 の /authorize エンドポイントに送る際に、両方のパラメーターもあわせて渡す必要があります。
ブラウザーで Cookie を無効にした状態でユーザーが https://{yourDomain}/authorize にアクセスすると、Auth0 はユーザーをアプリケーションのログイン URI にリダイレクトします。アプリケーションのログイン URI が設定されていない場合は、代わりにテナントのログイン URI にリダイレクトされます。
ユーザーをログインページに戻すと、リダイレクト ループが発生するおそれがあります。この問題を回避するには、ランディングページを使用して Cookie が利用可能かどうかを確認し、無効になっている場合は、続行するには有効にする必要があることをユーザーに通知してください。