リスクと注意事項
IdP 主導 フローにはセキュリティ上のリスクがあるため、推奨されません。可能な限り、SP-Initiated フローを使用することを推奨します。 IdP 主導 SSO を有効にする前に、リスクを十分に理解してください。このシナリオでは、Auth0 は IdP からの未承諾のレスポンスを受け取り、アプリケーションは Auth0 からの未承諾のレスポンスを受け取ります。どちらも、ユーザー自身がそのフローを開始したことを確認できません。そのため、このフローを有効にすると、攻撃者が正当なユーザーをだまして、攻撃者のアイデンティティで気付かないうちにアプリケーションへログインさせる Login CSRF attack を受けるおそれがあります。OpenID Connect の IdP 起点フロー
Connect (OIDC) は、IdP 起点フローという考え方をサポートしていません。したがって、Auth0 では SAML IdP 起点フロー (SAML 接続からのフロー) をアプリケーション向けの OIDC レスポンスに変換できますが、OIDC/OAuth 2.0 プロトコルを適切に実装しているアプリケーションは、要求していないレスポンスを拒否します。 OIDC アプリケーションを使用する場合は、アプリケーションにログイン エンドポイントを作成するのが最善です。このエンドポイントの唯一の目的は、IdP (Auth0 テナント) へのリダイレクトを開始することです。 複数の IdP を使用する場合は、ログイン エンドポイントをアイデンティティプロバイダーごとに用意するか、どの IdP がワークフローを開始したのかを識別するためのパラメーターを受け取れるようにしてください。 別の方法として、ユーザーがアプリケーション側からログインを開始するようにすることもできます。Post-back URL
IdP 主導 SSO を使用する際は、Post-back URL にconnection パラメーターを必ず含めてください。
Organizations機能を使用している場合は、必要に応じて、対象の組織の組織IDを含む organization パラメーターを指定できます:
この方法でユーザーが正常にログインするには、対象の接続がその組織で有効になっている必要があります。さらに、有効にした接続に対して自動メンバーシップを設定するか、ユーザーがその組織のメンバーシップを持っていることを確認する必要があります。
Lock/Auth0.js
認証結果の処理に Lock または Auth0.js を使用するシングルページアプリケーションの場合、IdP 主導フローを許可し、その結果としてアプリケーションが Login CSRF 攻撃を受ける可能性があることを、明示的に指定する必要があります。 Auth0.js を使用している場合は、ライブラリのwebAuth.parseHash を更新し、フラグ __enableIdPInitiatedLogin を true に設定する必要があります。
const lock = new Auth0Lock(clientID, domain, options)
フラグ自体は次のとおりです。
var options = { _enableIdPInitiatedLogin: true };
enableIdPInitiatedLogin フラグは、Lock で使用する場合は先頭にアンダースコアが 1 つ付き、auth0.js ライブラリで使用する場合はアンダースコアが 2 つ付く点に注意してください。
IDP-initiated SSO を設定する
- Dashboard > Authentication > Enterprise に移動し、SAMLP Identity Provider を選択します。
-
設定 で、IdP 主導 SSO の構成を確認できます。

- IdP-initiated SSO Behavior: このオプションでは、SAML 接続での IdP 主導 ログインを有効にできます。Accept Requests を選択し、必要なフィールドをすべて入力します。
- Default Application: IdP 主導 ログインが成功すると、ユーザーはこのアプリケーションに送られます。この設定には、この接続で有効になっている利用可能なアプリケーションが表示されます。ユーザーに IdP 主導 でログインさせるアプリケーションをドロップダウンから選択します。SAML 接続ごとに、IdP 主導 ログイン用に選択できるアプリケーションは 1 つだけです。
- Response Protocol: これは、選択した Default Application に接続するために使用されるプロトコルです。通常、アプリケーションは OpenID Connect プロトコルで構成されています (上記を参照) 。ただし、アプリケーションに SAML2 Web App アドオンを構成していて、SAML アサーションをルーティングしたい場合は、SAML を選択する必要があります。有効な SAML Assertion が postback URL に渡されると、Auth0 は選択したレスポンスプロトコルを使って、構成済みのデフォルトアプリケーションの最初の許可済みコールバック URL にログインレスポンスを送信します。OIDC を使用している場合は、クエリ文字列フィールドで
redirect_uriを指定することで、これを変更できます。- アプリケーションに構成されたコールバック URL に 複数のカスタムドメイン (MCD) のプレースホルダーが含まれている場合、システムは、IdP からの最初のリクエストを受信した postback URL のカスタムドメインに対応するメタデータ値を使って、その値を動的に設定します。詳しくは、Multiple Custom Domains を参照してください。
- Query String: OpenID Connect プロトコルを使用する場合、クエリ文字列オプションを使って動作をカスタマイズできます。query string でパラメーターを設定するのと同じように、複数のオプションを指定できます。設定できる内容は次のとおりです。
クエリ文字列の例:
redirect_uri=https://jwt.io&scope=openid email&response_type=token