メインコンテンツへスキップ
特定のケース (以下で説明) では、Auth0 が OIDC のサードパーティ主導ログインを使用して、アプリケーションの Login Initiation エンドポイントにリダイレクトする必要が生じる場合があります。詳しくは、OpenID FoundationInitiating Login from a Third Party を参照してください。 これらの URI は、Dashboard の Application Settings または Tenant Advanced Settings、あるいは を使用して設定できます。

login_url は、最終的に Auth0 の /authorize エンドポイントにリダイレクトされる、アプリケーション内のルートを指す必要があります。たとえば、https://mycompany.org/login です。https である必要があり、localhost を指定することはできません。login_url には、クエリパラメータや URI フラグメントを含めることができます。 OIDC の Third Party Initiated Login 仕様に従い、Issuer Identifier を含む iss パラメータは、リダイレクト前にクエリ文字列パラメータとして login_url に追加されます。

メタデータプレースホルダーを含む動的ログイン URI

Multiple Custom Domains または Organizations を使用している場合は、アプリケーションレベルの initiate_login_uri にメタデータプレースホルダーを含めるように設定できます。これらのメタデータプレースホルダーは、実行時に動的に置き換えられます。

サポートされるプレースホルダー

PlaceholderSourceExample
{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 でのみサポートされます。

フォールバック動作

プレースホルダーを解決できない場合、Auth0 はテナントレベルの 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 はエラーページを表示します。

パスワードリセットフローの完了

パスワードリセットフローの完了後、アプリケーションまたはテナントのデフォルト URI が設定されている場合は、ログインページに戻るためのボタンがユーザーに表示されます。 この動作は、 を有効にしている場合にのみ発生します。Classic Login の場合は、Change Password テンプレートでリダイレクト URL を設定する必要があります。詳細については、メールテンプレートのカスタマイズを参照してください。 Universal Login を使用するテナントでは、/post-password-change エンドポイントにより、ユーザーを特定のアプリケーションにリダイレクトできます。client_id が指定され、アプリケーションのログイン URI が設定されている場合、パスワードリセットの完了後にアプリケーションへ戻るためのボタンがユーザーに表示されます。

メールアドレス確認フロー全体

サインアップ プロセスの一環として、識別子としてメールアドレスを選択したユーザーには、メールアドレスを確認するためのメールが送信されます。ユーザーがそのリンクをクリックすると、メールアドレスが確認されたことを示すページが表示され、アプリケーションに戻るためのボタンが表示されます。そのボタンをクリックすると、ユーザーはログイン ページにリダイレクトされ、すでに有効なセッションがある場合は、そのままアプリケーションにリダイレクトされます。 この動作は、Universal Login が有効になっている場合にのみ発生します。Classic Login では、Verification Email テンプレートでリダイレクト URL を設定する必要があります。

組織メンバーを招待する

ユーザーが組織への参加に招待されると、メールで招待リンクを受け取ります。ユーザーがそのリンクをクリックすると、招待固有のパラメーターが追加された、設定済みのデフォルトのログインルートにリダイレクトされます。 たとえば、組織を有効にしたアプリケーションがあり、Application Login URIhttps://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 が利用可能かどうかを確認し、無効になっている場合は、続行するには有効にする必要があることをユーザーに通知してください。

詳しくはこちら