IdP イニシエーター SSO と SP イニシエーター SSO#

用語#

• Identity Provider (IdP): ユーザーのアイデンティティを保存および認証するサービス。
• Service Provider (SP): ユーザーにサービスを提供するウェブまたはサービス。
• Single Sign-On (SSO): セッションおよびユーザー認証サービスで、ユーザーが 1 つのログイン資格情報セット (例: 名前とパスワード) で複数のアプリケーションにアクセスできるようにします。
• SAML: セキュリティアサーションマークアップ言語は、特にアイデンティティ プロバイダーとサービス プロバイダーの間で認証と認可データを交換するためのオープンスタンダードです。 SSO によく使用されるプロトコルです。IdP によってユーザーが正常に認証されると、IdP は SP に SAML アサーションを送信し、SP はそれを検証してユーザーにアクセスを許可します。
• OIDC: OpenID Connect は、SSO のためのより近代的で安全なプロトコルです。それは OAuth 2.0 の上に構築されており、IdP によって実行された認証に基づいてユーザーの身元を確認する方法を提供します。IdP によってユーザーが正常に認証されると、IdP は JWT 形式のトークンを SP に送信し、SP はそれを検証してユーザーにアクセスを許可します。

SP イニシエーター SSO#

その名前の通り、SP イニシエーター SSO はサービス プロバイダーによって開始されます。ユーザーは SP のウェブサイト上のリソースにアクセスすることで認証プロセスを開始します。その後、SP は IdP への認証のためにユーザーをリダイレクトします。ユーザーが認証されると、IdP はトークン (OIDC) または SAML アサーション (SAML) を生成し、それを SP に送り返します。SP はトークンまたはアサーションを検証し、ユーザーにアクセスを許可します。

1. ユーザーが SP のウェブサイトを訪問し、リソースにアクセスしようとします。
2. ユーザーは SSO プロバイダーのログインボタン (例: Google, Azure AD, Okta など) をクリックします。
3. SP は認証のためにユーザーを IdP にリダイレクトします。
4. ユーザーは IdP にログインします。
5. IdP はトークンまたはアサーションを SP に送信します。
6. SP はトークンまたはアサーションを検証し、ユーザーにアクセスを許可します。

IdP イニシエーター SSO#

SP イニシエーター SSO とは異なり、IdP イニシエーター SSO はアイデンティティ プロバイダーによって開始されます。ユーザーは IdP のウェブサイトから認証プロセスを開始します。通常、ユーザーは IdP のポータルでサポートされている SP アプリケーションのリストを見つけます。ユーザーが SP アプリケーションをクリックすると、事前認証されたアイデンティティを持って SP のウェブサイトにリダイレクトされます。

1. ユーザーが IdP にログインします。
2. ユーザーは IdP のポータルを訪問し、SP アプリケーションを選択します。
3. IdP はユーザーの現在のセッションを検証し、事前認証された SSO アイデンティティでユーザーを SP にリダイレクトします。
4. SP は SSO アイデンティティを検証し、ユーザーにアクセスを許可します。

IdP イニシエーター SSO と SP イニシエーター SSO#

IdP イニシエーター SSO の利点#

IdP イニシエーター SSO は、ワークデイやセールスフォースなど、さまざまなサードパーティアプリまたはサービスに依存する大企業や組織によって多く採用されています。複数のアプリケーションに対するユーザーアクセスを管理し、SSO 認証を強制するための集中化された方法を提供します。IdP イニシエーター SSO を有効にすることで、従業員は各アプリケーションのウェブサイトを訪問する必要なく、IdP のポータルから接続されたアプリケーションに直接アクセスできます。これにより、オンボーディング時間を短縮し、ユーザーエクスペリエンスが向上します。

IdP イニシエーター SSO のリスク#

IdP イニシエーター SSO は、SP イニシエーター SSO と比較してリスクが高くなります。

1. 認証コンテキストの欠如: IdP から開始されたすべての認証要求は無許可です。したがって、SP は認証プロセスを開始し、承認されていないアクセスを開く可能性があります。ユーザーのセッションが乗っ取られるリスクがあります。悪意のあるアクターはユーザーの知らないうちに、または同意を得ずに正当なユーザーのためにログインプロセスを開始する可能性があります。

2. セッション固定: SP が認証プロセスを開始しないため、ユーザーのセッションは IdP のセッションに固定される可能性があります。これにより、攻撃者がユーザーのセッションを IdP のセッションに固定し、ユーザーアカウントへの不正アクセスを得るセッション固定攻撃が行われる可能性があります。

3. フィッシング攻撃: IdP イニシエーター SSO はフィッシング攻撃に対して脆弱である可能性があります。悪意のあるアクターはユーザーを偽の IdP ポータルに誘導し、ユーザーの資格情報を盗む可能性があります。ユーザーがログインした後、攻撃者は事前認証されたアイデンティティでユーザーを SP にリダイレクトする可能性があります。

4. リクエスト検証の保証がない: SP イニシエーター SSO では、通常、SP はリクエストの整合性を維持するために必要なセキュリティ情報を含めて IdP にリクエストを送信します。SP が認証応答を受信すると、これらの情報を検証して CSRF 攻撃を防ぎます。例: OIDC の state パラメータと SAML の RelayState。しかし、IdP イニシエーター SSO では、SP が認証プロセスを開始しないため、SP はリクエストの検証に保証を持ちません。

IdP イニシエーター SSO の制限事項#

IdP イニシエーター SSO は上記の脆弱性のため、OIDC ではサポートされていません。OIDC はリクエストの整合性を保証するために、SP が認証プロセスを開始する必要があります。例外的な状況であっても、ユーザーが SP ではない第三者から認証プロセスを開始する場合、最初にユーザーを SP に導く必要があります。

ただし、SAML では IdP イニシエーター SSO が可能です。IdP は SP の認証プロセスを開始せずに SAML アサーションを生成することができます。SAML IdP イニシエーター SSO では、適切な RequestID および RelayState なしで SAML アサーションを SP の ACS URL に直接送信することができます。SP はこの種のアサーションを処理し、ユーザーにアクセスを許可する必要があります。（注: RequestID と RelayState がない場合、SP はリクエストの整合性について保証を持ちません）。

結論#

IdP イニシエーター SSO は、複数のアプリケーションへのユーザーアクセスを集中管理する方法を提供しますが、SP イニシエーター SSO と比較してリスクが高くなります。SP イニシエーター SSO はより安全であり、認証リクエストの整合性に対する保証を提供します。OIDC と SAML の両方の SSO については、SP イニシエーター SSO を使用することをお勧めします。