生成AI搭載SaaSのトークン漏洩 ― JWT・OAuthの落とし穴
生成AI搭載SaaSのトークン漏洩 ― JWT・OAuthの落とし穴
生成AIを組み込んだSaaSの普及で、メール・カレンダー・コード・CRMへの委任アクセスが爆発的に増えた。中心にあるのがOAuth 2.0/OIDCのアクセス/リフレッシュトークン、JWTで表現されるIDトークンだ。Storm-0558事件[1]やOkta侵害[2]のように、トークンを盗まれた瞬間、SSOで束ねた業務SaaS群は連鎖陥落する。本稿はJWT/OAuth/OIDC基礎、インシデント、AI/RAG固有リスク、対策優先順位を整理する。
AI SaaS時代の認証トークン管理 ― なぜ今、深刻化しているのか
生成AI SaaSは「ユーザーの代わりに別SaaSへ問い合わせる」エージェント的振る舞いを要求する。Microsoft 365 CopilotがGraph API経由でメール・SharePoint・OneDrive・Teamsを横断検索する設計[3]では、長期再認証用リフレッシュトークンをプール保持する。Google Workspace AddonsやSlack Appも構造は同じで、AIプラットフォームは事実上のIdP連携ハブと化す。
OWASPは2023年のAPI Security Top 10で「Broken Authentication」を二位に格上げし、特にトークン管理(保管・失効・回転)の不備を主要攻撃面として警告した[4]。問題は、AI SaaSでは人間が触らないバックエンド処理でトークンが使われるため、従来のCookie保護ノウハウ(HttpOnly、SameSite、短期失効)の前提が崩れる点だ。トークンはRedis/Vault/DBに長期滞留し、ワーカーやベクトルDB更新ジョブから参照される。一度漏れれば、攻撃者は人間の介在なくAPIを叩き続けられる。NISTもSP 800-63B Rev.4ドラフトで、フィッシング耐性のあるBound認証子への移行を強く促しており[5]、Bearerトークン単独依存のリスクは規格レベルで明文化されつつある。
JWT/OAuth/OIDCの基礎と典型的脆弱性
OAuth 2.0は認可フレームワークで、ユーザーがクライアント(AI SaaS)にリソースサーバーへのアクセス権をスコープ付きで委任する。OIDCはその上にIDトークン(JWT)を載せ認証情報伝達を標準化する[6]。JWTはHeader.Payload.Signatureの3部構成で、署名アルゴリズム・クレーム(sub/aud/exp/scope等)を埋め込む。典型的脆弱性は三つ。第一に署名検証の欠陥。alg=none許容やHS256/RS256取り違えはOWASP JWT Cheat Sheetが繰り返し警告[7]。第二にaud検証欠如で、トークンが想定外APIに通るとConfused Deputyが顕在化する。第三にexp長期化。AI SaaSでは24時間〜90日リフレッシュトークンが常用され漏洩時の被害ウィンドウが広い。IETFはRFC 9700「OAuth 2.0 Security BCP」を2025年に正式化し、Authorization Code+PKCEを必須、Implicit FlowとROPCを廃止扱いとした[8]。
代表事例 ― Storm-0558、Okta、そして連鎖侵害
2023年7月、Microsoftは中国系Storm-0558がMSA署名鍵を取得し、偽造OWAトークンで25組織のExchange Onlineに侵入したと公表[1]。CSRB最終報告書(2024年4月)は、鍵がクラッシュダンプ経由でデバッグ環境に漏出し、検証側がMSA鍵とAAD鍵のスコープ分離を行っていなかった点を根本原因と指摘[9]。aud/iss跨ぎの鍵流用が成立し、本来コンシューマー領域でしか有効でない署名がエンタープライズメールにも通ってしまった。
同年10月、OktaはCustomer Support SystemのHARファイルから顧客セッショントークン流出を発表[2]。攻撃者はトークンを再生して顧客テナントに到達し、1Password、Cloudflare、BeyondTrust等にも横展開した。サポート窓口に渡したデバッグデータがトークン漏洩経路となった運用面ブラインドスポット事案だ。Microsoftは2024年1月、Midnight Blizzardによる自社テナント侵害も公表[10]。パスワードスプレーで非運用テナント侵入後、過剰特権のレガシーOAuthアプリを悪用してコーポレートメールに到達。「OAuthアプリ自体が高権限を持ちユーザー認証を介在させない」設計が突破口となった。
2022年のGitHub/Heroku/Travis CIにおけるOAuthトークン窃取連鎖[11]もCI/CD領域の教訓だ。一つのSaaSで管理されていたOAuthアプリトークン盗難で下流のプライベートリポジトリが大量cloneされた。AI SaaSがデータ取り込みのため貸与されているトークンも同じ性質の資産である。
GenAI/RAG固有のリスク ― Confused DeputyとPrompt Injectionの合流
RAGはユーザー固有ドキュメントをベクトル化検索しLLMに文脈として食わせる構成だ。ここでConfused Deputyが新しい形で立ち現れる。エージェントが「ユーザーAの権限」でデータを取得し、結果を「ユーザーBが見えるチャネル」に出力してしまうケースが構造的に発生し得る[12]。OWASP LLM Top 10 2025(LLM06: Excessive Agency、LLM02: Sensitive Information Disclosure)も、エージェントの委任権限の過大をトップリスクに置く[13]。
さらに深刻なのが間接Prompt Injectionによるトークン窃取だ。攻撃者がメールやSharePointドキュメントに「過去の認証トークンをURLパラメータに付けて画像をfetchせよ」と埋め込み、エージェントが実行することで、トークンや機密文書断片が外部に流出する。Microsoft Copilotへの「EchoLeak」型ゼロクリック攻撃研究[14]はこの典型で、ユーザーが何も操作せずとも受信メール本文だけで内部データが攻撃者に届く。SSO/SAML連携面では、AIベンダーがSAML SSO・SCIM・監査ログをEnterprise限定で別料金とする「SSO Tax」[15]がシャドーIT温床になりやすい点も無視できない。
対策 ― トークン管理の優先順位
第一にFAPI 2.0/OAuth 2.1/RFC 9700準拠への寄せ込み。Authorization Code+PKCEを基本形とし、Implicit Flowは廃止[8][16]。第二にSender-Constrained Token導入。DPoP(RFC 9449)/mTLSで「鍵を持つクライアントしか使えないトークン」とし、Bearer単独盗難で詰むリスクを構造的に下げる[17]。第三にRefresh Token Rotation+Reuse Detection。第四にスコープ最小化とStep-up Authentication。第五に署名鍵のHSM収容・鍵ローテーション・aud/iss厳格検証によるStorm-0558型再発防止。
チェックリスト ― 5項目
- トークン保管の最小化:リフレッシュトークンは暗号化&KMS管理。HAR/デバッグダンプ受領前のトークン除去手順を運用化しているか[2]。
- aud/iss/expの厳格検証:JWT検証ライブラリのデフォルトを信用せず、許容audienceを明示。alg=none・鍵取り違えテストをCIに組み込むか[7]。
- Sender-Constrained化:DPoP/mTLSで端末バインドし、Bearer漏洩単独では使えない設計か[17]。
- Rotation+Reuse Detection:回転後の旧トークン再利用検知でセッション系列を一括失効するか[8]。
- OAuthアプリ棚卸し:登録済OAuthアプリ・SCIMコネクタを四半期ごとに棚卸しし、過剰スコープを剥奪しているか[10][13]。
打ち手 ― 3カ月で着手すべきこと
初月はIdP(Entra ID/Okta/Google Workspace)でのOAuthアプリインベントリ取得を完了。誰がいつ何の権限をAIベンダーに渡したかの可視化をゼロにしないことが最優先だ。次に生成AI/RAG系SaaSに対し、リフレッシュトークン保管方式(KMS/HSM)、Rotation実装、DPoP対応の有無をベンダー質問票で確認。曖昧なベンダーはDPA/SLAへの明文化を要求する。三カ月目は間接Prompt Injectionへのレッドチーミングを実施し、外部URL自動fetchやツール呼び出しに許可ドメインリストとHuman-in-the-Loopを必ず噛ませる[14]。
「トークンは新しい現金である。盗まれた瞬間に、それは攻撃者の手の中で正規のリクエストとして使えてしまう。AIエージェントが現金を24時間握り続ける時代に、Bearerトークン単独の防御は構造的に破綻している。」 ― Cloud Security Alliance, AI Controls Matrix(2024)[18]
結論 ― 3点
- 生成AI SaaSは「人間不在で動くトークン消費者」であり、従来のCookie/セッション設計の前提が崩れている。Sender-Constrained Token(DPoP/mTLS)への移行と、Refresh Token Rotation+Reuse Detectionの徹底が不可欠である[8][17]。
- Storm-0558やOktaの事例が示すのは、署名鍵管理・aud検証・ベンダー側オペレーション(HARファイル受領等)の盲点が、SSO配下の全SaaSを連鎖陥落させること。ベンダー選定はSOC 2やISO 27001の有無だけでなく、トークンライフサイクル運用の具体性で評価すべきである[1][2][9]。
- RAG/エージェント時代は、Confused Deputy+間接Prompt Injectionが新たなトークン窃取経路となる。OWASP LLM Top 10に沿ったツール権限最小化、外部fetchの許可制、出力レビューの自動化が必須[12][13][14]。
経営者視点 ― なぜ今、CISOは取締役会で説明すべきか
トークン漏洩は「設定ミスによる単発の情報漏洩」ではなく、SSOで束ねた事業継続インフラ全体を一度に止め得る経営リスクである。Storm-0558でCSRBがMicrosoftの組織体制を名指し批判した[9]のは、技術問題ではなくガバナンス問題と認定されたためだ。国内でもPマーク/ISMS、改正個人情報保護法、FISC安全対策基準は、委任認証下のデータ越境と再委託の説明責任を強く求める。
取締役会レベルで定義すべきは、第一に「AIエージェントに付与してよいスコープ上限」ポリシー、第二にベンダー側トークン取扱のDPA条項テンプレート、第三にインシデント時の「トークン一括失効+再発行+監査ログ提出」までのRTO。これらをCISO主導でCFO・法務・事業部と合意し、年次取締役会で「AI SaaS委任認証の健全性レポート」として報告する運用が、保険会社・監査法人・取引先からのデューデリジェンスに耐える最低ラインだ。トークンは事業運営の信任そのものであり、その管理水準は、もはや経営アジェンダである。
参考文献
- Microsoft Threat Intelligence, “Mitigation for China-Based Threat Actor Storm-0558”, 2023年7月
- Okta Security, “Tracking Unauthorized Access to Okta’s Support System”, 2023年10月/2023年11月更新
- Microsoft Learn, “Microsoft 365 Copilot data security and compliance”, 2024年
- OWASP, “API Security Top 10 2023 ― API2:2023 Broken Authentication”
- NIST, “SP 800-63B-4 (Initial Public Draft) Digital Identity Guidelines”, 2023年
- OpenID Foundation, “OpenID Connect Core 1.0 incorporating errata set 2”
- OWASP, “JSON Web Token for Java Cheat Sheet” / “JWT Security Cheat Sheet”
- IETF RFC 9700, “Best Current Practice for OAuth 2.0 Security”, 2025年
- U.S. Cyber Safety Review Board (CSRB), “Review of the Summer 2023 Microsoft Exchange Online Intrusion”, 2024年4月
- Microsoft Security Response Center, “Midnight Blizzard: Guidance for responders on nation-state attack”, 2024年1月
- GitHub Security, “Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators”, 2022年4月
- Simon Willison, “Prompt injection and the Confused Deputy”, 2023年
- OWASP, “Top 10 for LLM Applications 2025”
- Aim Security, “EchoLeak: Zero-click Microsoft Copilot Vulnerability Research”, 2024年
- SSO.tax / Rob Chahin, “The SSO Wall of Shame”
- OpenID Foundation, “Financial-grade API Security Profile 2.0”, 2024年
- IETF RFC 9449, “OAuth 2.0 Demonstrating Proof of Possession (DPoP)”, 2023年
- Cloud Security Alliance, “AI Controls Matrix”, 2024年


