公開日
仲介型SSO、ブローカーの20%が脆弱！あなたの認証基盤は大丈夫？
シングルサインオンは、一度の認証で複数のサービスを利用可能にする便利な仕組みとして、多くのウェブサイトで採用されています。しかし、その利便性の裏で、新たなセキュリティリスクが静かに広がっていることをご存知でしょうか？特に、サービスプロバイダとアイデンティティプロバイダの間に「アイデンティティブローカー」と呼ばれる仲介役が存在する「仲介型SSO」において、これまで見過ごされてきた脆弱性が明らかになりつつあります。
本記事では、セキュリティ分野のトップカンファレンスの一つであるIEEE Symposium on Security and Privacy(2025年)で発表された論文「“Only as Strong as the Weakest Link”: On the Security of Brokered Single Sign-On on the Web」に基づき、この仲介型SSOに潜むセキュリティ上の課題を深掘りします。この研究は、仲介型SSOエコシステムの包括的な調査を通じて、具体的な脅威とその深刻な影響を明らかにしました。
そもそも仲介型SSOとは？従来のSSOとの違いと、なぜ広まっているのか
従来のSSOと「ブローカー」が入る仲介型SSOの仕組み
従来のシングルサインオン（SSO）は、主に「ユーザー」「サービスプロバイダ（SP）」「アイデンティティプロバイダ（IdP）」の3者間で認証連携を行う仕組みです。ユーザーはあるIdP（例：Google、Facebook）のアカウントを使って、様々なSP（ウェブサイトやアプリケーション）にログインできます。
これに対し「仲介型SSO」では、この3者に加えて「アイデンティティブローカー（Broker）」という新たなアクターが加わります。以下の図は、従来の3者間SSOと仲介型SSOの構成要素とフローの違いを示しています。
従来の3者間SSOと仲介型SSOの比較
仲介型SSOでは、SPは直接IdPと連携するのではなく、まずブローカーに認証を委任します。そしてブローカーがIdPとの認証連携を行い、最終的にSPに対して認証結果を返すという流れになります。
仲介型SSOのメリットと「アイデンティティブローカー」の役割
では、なぜSPはブローカーを介した仲介型SSOを導入するのでしょうか？主なメリットは、SP側の実装負担の軽減です。複数のIdP（Google, Facebook, Appleなど多数）に対応しようとすると、SPはそれぞれのIdPの仕様に合わせて個別に認証連携を実装・保守する必要があり、これは大きな開発コストと手間を伴います。
アイデンティティブローカーは、この複雑な処理を肩代わりしてくれる存在です。SPは一度ブローカーと連携するだけで、そのブローカーがサポートする多数のIdPへのSSOログインをユーザーに提供できるようになります。これにより、SP開発者は認証機能の実装から解放され、本来のサービス開発に集中できるのです。また、IdP側の仕様変更があった場合も、ブローカー側で吸収してくれるため、SP側での対応は基本的に不要となります。Keycloak、Amazon Cognito、Google Firebaseなどが著名なブローカーとして知られています。
実態調査：SSO利用サイトの25%が既に仲介型SSOを導入
本論文の研究チームは、IDB-DETECTORという自動検出ツールを開発し、世界のウェブサイトをアクセス数でランク付けしたリストである「Tranco Top 1M」の上位100万サイトを対象に仲介型SSOの利用状況を調査しました。その結果、SSOログイン機能を持つウェブサイトのうち、実に25%が認証に何らかのブローカーを統合していることが明らかになりました。
世界の主要100万ウェブサイトにおける仲介型SSOの利用状況
| カテゴリ | ブローカーの種類 | ブローカー数(%) | フロー数(%) | ウェブサイト数(%) |
|---|---|---|---|---|
| 3者間SSO | 39,870 (72%) | 24,880 (75%) | ||
| 仲介型SSO | パブリック | 64 (26%) | 10,911 (71%) | 5,944 (72%) |
| インターナル | 117 (47%) | 3,442 (22%) | 1,635 (20%) | |
| 不明 | 68 (27%) | 1,139 (7%) | 686 (8%) | |
| 合計（仲介型SSO） | 249 (100%) | 15,213 (28%) | 8,241 (25%) | |
| 総計（全SSO） | 55,083 (100%) | 33,121 (100%) |
これは、これまでセキュリティ研究の分野で十分な注目が集まってこなかった仲介型SSOが、既にウェブ上で広く普及している実態を示しています。そして、この新たな「仲介役」の存在が、予期せぬセキュリティリスクを生み出しているのです。
仲介型SSOに潜む見過ごせない3大セキュリティ脅威
本論文では、仲介型SSOに特有のセキュリティ上の問題点を網羅的に分析し、主に以下の3つのカテゴリの脅威が存在することを突き止めました。
脅威1：インジェクション攻撃の危険性
仲介型SSOでは、認証プロセスにおけるリダイレクトの回数が増え、その経路も複雑になります。このリダイレクトチェーンの検証がブローカー側で不十分な場合、攻撃者による不正なメッセージの挿入（インジェクション攻撃）を許し、認証情報や個人情報が窃取される危険性があります。
脅威2：不正アクセスとアカウント乗っ取りリスク
ユーザーがSPに対してデータアクセスを許可する「同意」のプロセスも、仲介型SSOではブローカーが介在することで複雑化します。ブローカーの権限管理の設計によっては、ユーザーが意図しない形で悪意のあるSPにまでデータアクセス権限が与えられてしまったり、最悪の場合、アカウントが乗っ取られたりする可能性があります。
脅威3：セキュリティベストプラクティス(SBCPs)違反
OAuth 2.0やOpenID Connectといった認証プロトコルには、安全な実装のための指針であるセキュリティベストプラクティス（SBCPs）が定められています。しかし、仲介型SSOの導入において、これらのSBCPsがブローカーによって遵守されず、結果としてシステム全体のセキュリティレベルが低下してしまうケースが確認されています。
次章からは、これらの脅威について、論文で報告された具体的なメカニズムや事例を交えながら、より詳しく解説していきます。
なぜリダイレクトが危険なのか？仲介型SSOの複雑な経路
仲介型SSOにおけるリダイレクトチェーンの仕組みとその複雑性
シングルサインオンのプロセスでは、ユーザーのブラウザはSPからIdPへ、そしてIdPからSPへとリダイレクトを繰り返すことで認証処理が進みます。仲介型SSOでは、このリダイレクトの途中にブローカーが挟まるため、リダイレクトのステップがさらに増え、認証フロー全体がより複雑になります。
この複雑化したリダイレクトチェーンは、攻撃者にとって新たな攻撃経路となり得ます。特に、各リダイレクト先URLの検証が不十分な場合、攻撃者は正規の認証フローに割り込み、悪意のある操作を行うことが可能になります。
特に危険なリダイレクトパターン：「順不同チェーン」と「オープンエンドチェーン」とは
本論文では、仲介型SSOにおけるリダイレクトチェーンのパターンを分析し、主に3つのタイプを特定しました。「二重チェーン（Double Chain）」「順不同チェーン（Out-of-Order Chain）」「オープンエンドチェーン（Open-End Chain）」です。
仲介型SSOにおけるリダイレクトチェーンのパターン
このうち、「二重チェーン」は、SPからブローカー、ブローカーからIdP、そしてその逆という正規のステップを踏むため、比較的安全とされています。しかし、「順不同チェーン」では、IdPからの応答がブローカーを経由せずに直接SPに返ってしまったり、「オープンエンドチェーン」では、ブローカーからの応答が認証を開始したSPとは異なるドメインのSPに返ってしまったりするケースが確認されました。
これらの不規則なリダイレクトフローは、設計上、クロスサイトリクエストフォージェリ（CSRF）攻撃に対して脆弱になります。なぜなら、SPは認証応答の正当性を検証するための「state」パラメータを正しく比較できなくなるため、攻撃者が偽の認証応答を送り込むことが容易になるからです。
調査結果：ブローカーの20%がリダイレクト検証に失敗、最悪アカウント乗っ取りも
驚くべきことに、本論文の調査対象となった249のブローカーのうち、49のブローカー（約20%）がリダイレクト先のURL検証を適切に行っていませんでした。
仲介型SSOにおけるリダイレクトチェーンの不十分な検証結果
| 脆弱なブローカー数 | オープンリダイレクト | XSS | トークン漏洩 | ユーザーデータ漏洩 | アカウント乗っ取り | 影響を受けるSP数 |
|---|---|---|---|---|---|---|
| 20 | ✔ | ― | ✔ | ✗ | ✔ | 1,093 |
| 9 | ✔ | ✗ | ✔ | ✗ | ✔ | 610 |
| 8 | ✔ | ― | ✗ | ✗ | ✗ | 337 |
| 5 | ✔ | ✔ | ✔ | ✗ | ✔ | 247 |
| 2 | ✔ | ✗ | ✗ | ✗ | ✗ | 94 |
| 1 | ✔ | ✔ | ✗ | ✔ | ✗ | 17 |
| 1 | ✗ | ✔ | ✗ | ✗ | ✗ | 11 |
| 1 | ✔ | ― | ✗ | ✔ | ✗ | 5 |
| 1 | ✔ | ✗ | ✔ | ✗ | ✗ | 4 |
| 1 | ✔ | ― | ✔ | ✗ | ✗ | 3 |
| 合計 49 | 48 | 7 | 36 | 2 | 34 | 2,421 |
これらの脆弱性は、オープンリダイレクトやクロスサイトスクリプティング（XSS）といった攻撃を可能にするだけでなく、ユーザーの認証トークンが攻撃者に漏洩し、結果として1,950ものSPでアカウントが乗っ取られる危険性があることを示しています。
「同意した覚えはないのに…」仲介型SSOの不正データアクセスの実態
本来あるべきSSOの同意メカニズムとユーザー保護
従来のSSOにおいて、ユーザーが初めてSPにログインする際には、IdPから「このSPにあなたのプロフィール情報（氏名、メールアドレスなど）へのアクセスを許可しますか？」といった同意確認画面が表示されます。これは、ユーザーが自身のデータがどのSPに提供されるのかを把握し、コントロールするための重要な仕組みです。GDPR（一般データ保護規則）などのプライバシー規制においても、このような明確な同意取得が求められています。
仲介型SSO特有の課題：「ブローカーへの暗黙の信頼」が招く危険
仲介型SSOの場合、この同意のプロセスが複雑になります。ユーザーはSPに対して同意を与えているつもりでも、実際にはそのデータはまずブローカーに渡り、そこからSPへと流れます。問題なのは、多くのケースで、ユーザーはブローカーの存在を意識しておらず、ブローカーに対して明示的な同意を与えていないという点です。
SPはブローカーを「信頼できる仲介役」として利用しますが、もしブローカーの権限管理の仕組みに不備があった場合、ユーザーが全く意図しない形で、悪意のある第三者にまで個人情報がアクセスされてしまうリスクが生じます。
3つのデータアクセスモデル：安全なモデルと危険な「不正アクセス」モデル
本論文では、ブローカーがSPとIdPの間でどのようにクライアントID（CID）を管理し、ユーザーデータへのアクセス権を制御しているかについて、3つの統合パターンを特定しました。
- セキュアデータアクセス: 各SPに対して個別のCIDがブローカーとIdPの間で発行・管理され、ユーザーはSPごとにデータアクセスへの同意を求められます。これは最も安全でプライバシーに配慮したモデルです。
- フェデレーテッドデータアクセス: 複数の信頼できるSP群（例えば同一企業が運営するサービス群）に対して、共通のCIDがIdPで利用されます。ユーザーは一度同意すれば、そのフェデレーション内のSPには再度同意を求められません。
- 不正アクセス: 最も問題のあるパターンで、ブローカーはIdPに対して単一のCIDのみを登録し、それを全てのSP（信頼できるか否かに関わらず）で使い回します。この場合、ユーザーがある信頼できるSPに一度同意を与えると、その同意が悪意のあるSPにまで適用されてしまう可能性があります。
調査結果：15のブローカーがユーザーデータを漏洩、6つのブローカーがアカウント乗っ取りを可能に
この「不正アクセス」モデルを採用しているブローカーは、ユーザーのプライバシーを深刻な危険にさらします。論文の調査では、18のブローカーがこの危険なパターンに該当し、そのうち15のブローカーが、ユーザーが一度も訪れたことのない、あるいは同意を与えた覚えのない悪意のあるSPに対して、ユーザーデータ（氏名、メールアドレスなど）へのアクセスを許してしまう脆弱性を持っていることが確認されました。影響を受けるSPは1,103にものぼります。
仲介型SSOにおける不正データアクセスの実態(IdP別)
| ブローカー名 | データ漏洩 | アカウント乗っ取り | 影響SP数(Facebook) | 影響SP数(Google) | 影響SP数(Apple) | 影響SP数(LinkedIn) | 影響SP数(Windows) |
|---|---|---|---|---|---|---|---|
| CivicPlus | ✔ | ✔ | 531 | - | - | - | - |
| uLogin | ✔ | ✗ | 188 | 130 | 16 | - | - |
| Growave | ✔ | ✔ | 102 | 107 | - | - | - |
| Hiko | ✔ | ✔ | 46 | 42 | 16 | 8 | 7 |
| Oxi | ✔ | ✔ | 43 | 48 | 10 | - | - |
| Okas | ✔ | ✗ | 35 | 38 | 14 | - | - |
| CONNECT | ✗ | ✗ | 21 | 21 | 12 | - | - |
| Login4Play | ✔ | ✔ | 17 | 21 | - | - | - |
| miniOrange | ✔ | ✗ | 16 | 12 | - | - | - |
| Mylo.id | ✗ | ✗ | 9 | 25 | 22 | 21 | - |
| NexusMedia EA | ✔ | ✗ | 9 | 7 | - | - | - |
| Salesforce CI | ✔ | ✗ | 6 | - | - | - | - |
| Zifyapp | ✔ | ✗ | 5 | - | - | - | - |
| Froonze | ✔ | ✗ | 4 | 2 | - | - | - |
| miniOrange SL | ✔ | ✗ | 2 | 2 | - | - | - |
| LiveRe | ✔ | ✔ | 2 | - | - | - | - |
| Xsolla | (検証不可) | (検証不可) | 2 | - | - | - | - |
| Hexgator | ✗ | ✗ | 1 | - | - | - | - |
| 合計: 18 | 15 | 6 |
さらに深刻なのは、これらのブローカーのうち6つが、スコープ（権限範囲）が限定されていない認証トークンを発行していた点です。これにより、攻撃者は信頼できるSP上のユーザーアカウントを完全に乗っ取ることが可能になり、799のSPがこのアカウント乗っ取りのリスクにさらされていました。
セキュリティの「最弱の環」はどこに？SBCPs違反の深刻な現状
なぜSBCPs（セキュリティベストプラクティス）が重要なのか？
OAuth 2.0やOpenID Connectといった認証プロトコルは、その複雑さゆえに誤った実装をすると重大な脆弱性を生み出す可能性があります。そのため、IETF（Internet Engineering Task Force）は、これらのプロトコルを安全に利用するための具体的な指針として「セキュリティベストプラクティス（SBCPs）」を公開し、定期的に更新しています。SBCPsには、CSRF攻撃対策のためのstateパラメータの適切な利用、コードインジェクション攻撃対策のためのPKCE（Proof Key for Code Exchange）の導入、リプレイ攻撃対策のためのnonceパラメータの利用などが含まれています。
調査で露呈：SPーブローカー間フローに潜む7000件以上のSBCP違反
仲介型SSOにおいても、当然ながらこれらのSBCPsは遵守されるべきです。しかし、本論文の調査によると、多くのブローカーがSBCPsを適切に実装していない、あるいはSPがSBCPsに準拠したリクエストを送っても、ブローカーがIdPとの通信の際にこれらのセキュリティ機能を意図的に除去・ダウングレードしてしまうケースが多数発見されました。
以下の表は、SPとブローカー間のフロー、およびブローカーとIdP間のフローにおけるSBCP違反の状況を示しています。
SBCP（セキュリティベストプラクティス）違反の状況
| 違反の種類 | 違反の詳細 | フロー (脆弱な実装) | フロー (非準拠の許容) | フロー (安全) | ウェブサイト (脆弱な実装) | ウェブサイト (非準拠の許容) | ウェブサイト (安全) |
|---|---|---|---|---|---|---|---|
| 不安全なフロー | 0 | 1,034 | 4,634 | 0 | 545 | 2,235 | |
| シークレット漏洩 | 0 | 0 | 5,668 | 0 | 0 | 2,780 | |
| PKCE欠落 | 2,954 | 2,698 | 16 | 1,505 | 1,273 | 2 | |
| 無効なPKCE | 0 | 89 | 5,579 | 0 | 41 | 2,739 | |
code なし | 0 | 17 | 5,651 | 0 | 9 | 2,771 | |
| 再利用 | 0 | 84 | 5,584 | 0 | 36 | 2,744 | |
| エントロピー < 128bit | 0 | 35 | 5,633 | 0 | 13 | 2,767 | |
| 無効なメソッド | 0 | 39 | 5,629 | 0 | 17 | 2,763 | |
state 欠落 | 7 | 1,021 | 4,640 | 7 | 543 | 2,230 | |
無効な state | 8 | 704 | 4,956 | 4 | 306 | 2,470 | |
| 再利用 | 8 | 697 | 4,963 | 4 | 300 | 2,476 | |
| エントロピー < 128bit | 0 | 141 | 5,527 | 0 | 78 | 2,702 | |
nonce 欠落 | 93 | 2 | 5,573 | 93 | 1 | 2,686 | |
無効な nonce | 305 | 1,866 | 3,557 | 263 | 858 | 1,659 | |
id_token なし | 304 | 1,786 | 3,578 | 262 | 846 | 1,672 | |
| 再利用 | 1 | 138 | 5,529 | 1 | 67 | 2,712 | |
| エントロピー < 128bit | 0 | 25 | 5,643 | 0 | 18 | 2,762 | |
| 総違反件数 | 3,367 | 7,415 | 1,872 | 3,568 |
- 脆弱な実装: ブローカーがセキュリティ機能を意図的に除去または弱体化させるケース。
- 非準拠の許容: ブローカーが、SP側からの脆弱な実装（SBCP非準拠）を許容してしまうケース。
特に、SPとブローカー間のフローにおいて、7,000件を超えるSBCP違反が確認され、これが仲介型SSOにおけるセキュリティの「最弱の環（Weakest Link）」となっていると結論付けられています。例えば、SPがPKCEを導入していてもブローカーがPKCE関連のパラメータをIdPに送らなかったり、stateやnonceといった重要な保護メカニズムが欠落していたりするケースです。これにより、本来保護されるべき認証フローが、ブローカーの介在によって脆弱なものへと変えられてしまっているのです。
まとめ：仲介型SSOのリスクを理解し、今こそセキュリティ対策の見直しを
仲介型SSOは、SPにとって認証機能の実装負担を軽減する魅力的なソリューションですが、本記事で見てきたように、決して「銀の弾丸」ではありません。ブローカーという新たなアクターの介在は、リダイレクト攻撃、不正アクセス、SBCP違反といった新たなセキュリティリスクを生み出し、ユーザーのデータを深刻な危険にさらす可能性があることを、私たちは再認識する必要があります。本論文は、仲介型SSOのセキュリティに関する包括的な調査を通じて、これまで見過ごされてきた多くの脆弱性を白日の下に晒しました。SSO利用サイトの実に25%が仲介型を導入しているという事実は、この問題の広範な影響を示唆しています。
この新たな脅威に対し、ウェブサイト開発者やセキュリティ担当者は、ブローカーの慎重な選定、定期的な脆弱性評価、SBCPsの徹底、インシデント対応計画の準備といった対策を講じる必要があります。本研究成果は、標準化団体やセキュリティコミュニティに対しても、仲介型SSOの課題への注意を喚起し、より安全なプロトコルやガイドライン策定を促すでしょう。開発者、ブローカー提供者、研究者が協力し、継続的に脅威情報を共有・対策することで、より安全で信頼性の高い認証エコシステムの構築が期待されます。利便性と安全性はトレードオフの関係にありますが、仲介型SSOにおいては、そのバランスを常に意識し、ユーザー保護を最優先に考える姿勢が不可欠です。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: