メインコンテンツへスキップ
場合によっては(以下を参照)、Auth0がOIDCサードパーティ起点のログインを使って、アプリケーションのログイン開始エンドポイントにリダイレクトしなければならないことがあります。詳細については、OpenID Foundationの「Initiating Login from a Third Party」をお読みください。 これらのURIは、Dashboardの[Application Settings(アプリケーション設定)][Tenant Advanced Settings(高度なテナント設定)]、またはで構成することができます。
  • アプリケーションレベル
  • テナントレベル
curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/clients/{yourClientId}' \
  --header 'authorization: Bearer API2_ACCESS_TOKEN' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --data '{"initiate_login_uri": "<login_url>"}'

login_urlは、Auth0の/authorizeエンドポイントにリダイレクトされるアプリケーションのルートをポイントします(例:https://mycompany.org/login)。これにはhttpsが必須で、localhostはポイントできません。login_urlには、クエリパラメーターとURIフラグメントを含めることができます。 OIDCサードパーティ起点のログイン仕様に基づいて、リダイレクトの前に、発行者識別子が含まれるissパラメーターが、クエリ文字列パラメーターとしてlogin_urlに追加されます。

デフォルトのログインルートにリダイレクトするシナリオ

ユーザーがログインページをブックマーク

アプリケーションがログインプロセスが開始すると、必要なパラメーターセットを使ってhttps://{yourDomain}/authorizeに移動します。Auth0は、エンドユーザーをhttps://{yourDomain}/loginページにリダイレクトし、URLは次のようになります。 https://{yourDomain}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&... stateパラメーターは内部データベースのレコードをポイントし、ここで認可トランザクションのステータスを追跡します。トランザクション完了時または一定時間の経過後、レコードは内部データベースから削除されます。 Organizationsを使用している場合、エンドユーザーが組織のログインプロンプトをブックマークに登録すると、Auth0がユーザーをデフォルトのログインルートにリダイレクトする際にorganizationパラメーターも含めます。 ユーザーがログインページをブックマークに登録して、その/login URLに移動すると、トランザクションレコードがなくなっているため、Auth0がログインフローを続行できないことがあります。この場合、Auth0はデフォルトのクライアントURL(構成されている場合)またはテナントレベルのURL(構成されていない場合)にリダイレクトします。デフォルトのログインURLが設定されていない場合は、エラーページが表示されます。

パスワードリセットフローを完了する

パスワードリセットフローを完了し、アプリケーションまたはテナントのデフォルトのURIが構成されると、ユーザーにログインページに戻るためのボタンが表示されます。 この動作は、ユニバーサルログインエクスペリエンスが有効な場合にのみ起こります。クラシックログインでは、Change Password(パスワード変更)テンプレートでリダイレクトURLを構成する必要があります。詳細については、「メールテンプレートをカスタマイズする」をお読みください。 ユニバーサルログインを使うテナントの場合、/post-password-changeエンドポイントは、ユーザーを特定のアプリケーションにリダイレクトする動作に対応しています。client_idが指定され、アプリケーションのログインURIが設定されている場合は、パスワードのリセット完了後にユーザーをアプリケーションに送り返すボタンが表示されます。
curl --request POST \
  --url 'https://{yourDomain}/api/v2/tickets/password-change' \
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  --header 'content-type: application/json' \
  --data '{ "user_id": "A_USER_ID", "client_id": "A_CLIENT_ID" }'

メール検証フローを完了する

サインアッププロセスの一環として、識別子にメールを選択したユーザーは、メールアドレスの確認メールを受信します。リンクをクリックすると、メールが確認されたことを示すページに移動し、アプリケーションに戻るためのボタンが提供されます。クリックすると、ログインページにリダイレクトされます。有効なセッションがすでに存在する場合は、アプリケーションにリダイレクトされることになります。 この動作は、ユニバーサルログインエクスペリエンスが有効な場合にのみ起こります。クラシックログインでは、Verification Email(確認メール)テンプレートでリダイレクトURLを構成する必要があります。

組織メンバーを招待する

ユーザーが組織への参加に招待されると、メールで招待リンクを受け取ります。リンクを選択すると、招待に特定のパラメーターが追加された構成済みのデフォルトログインルートにリダイレクトされます。 たとえば、組織対応のアプリケーションで [Application Login URI(アプリケーションログインURI)]https://myapp.com/loginに設定されている場合、エンドユーザーが受け取る招待メールには、以下のリンクが含まれます。https://myapp.com/login?invitation={invitation_ticket_id}&organization={organization_id}&organization_name={organization_name} そのため、アプリケーションのルートは、クエリ文字列でinvitationパラメーターとorganizationパラメーターを受け入れる必要があります。招待受諾トランザクションを開始するには、エンドユーザーとともに両方のパラメーターをAuth0の/authorizeエンドポイントに転送します。

無効になったクッキー

ブラウザーでクッキーが無効になった状態で、ユーザーがhttps://{yourDomain}/authorizeに移動すると、Auth0はユーザーをアプリケーションのログインURIにリダイレクトします。アプリケーションのログインURIが設定されていない場合、リダイレクトはテナントのログインURIに送信されます。 ユーザーをログインページに送り返すと、リダイレクトのループが発生する恐れがあります。この問題を回避するには、ランディングページを使ってクッキーの可用性を確認します。無効な場合は、続行にクッキーの有効化が必要なことをユーザーに警告します。

もっと詳しく

I