SAML、その仕組み：手紙の中の署名

この動画の要点

• SAML：内部から自身を署名するログイン
• 2002年：4つのXMLフォーマット、1つの委員会、1つの業界全体
• ログインのやり取り：アプリ → IDプロバイダ → ブラウザ経由で戻る
• アサーション：署名は署名対象の内部に存在する
• 正規化：すべてのバイトで合意するか、誰もログインできない

翻訳されたトランスクリプト

オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。

SAML：内部から自身を署名するログイン

0:00 SAMLは、あなたが持っているほとんどすべての仕事用アプリにログインさせるXMLです。 そしてその署名は、それが署名するドキュメントの内部に存在します。 封をする封筒の中に公証人がスタンプを押すように。 ある委員会がそれを書いてから10年後、研究者たちは14のSAML フレームワークをテストしました。11が失敗しました。 そして今週、Trail of Bitsの「ひどい設計のフラクタル」と呼ぶ投稿が Hacker Newsのトップページに載りました。 3分でわかる：ログインの仕組み、署名がどこに隠されているか、

0:27 そして皆が同意する解決策が別のプロトコルである理由。 これはThe Daily Diff、その仕組みです。

2002年：4つのXMLフォーマット、1つの委員会、1つの業界全体

0:34 2002年。 Oasisのセキュリティ委員会が、4つのベンダーXMLフォーマットを1つに統合しました。 大学が最初に採用し、その後Oktaがそれに基づいて会社を設立しました。 委員会の文書がこれほど早く収益に変わったことはありません。 アプリを開きます。

ログインのやり取り：アプリ → IDプロバイダ → ブラウザ経由で戻る

0:46 アプリはあなたが誰であるかを知らないので、ブラウザをIDプロバイダに転送します。 例えば、あなたの会社のOktaなどです。 そこでログインします。 Oktaは、あなたが誰であるかを示す署名付きXMLドキュメントをあなたのブラウザに渡し、 ブラウザはそれを送り返します。

アサーション：署名は署名対象の内部に存在する

0:59 そのドキュメントがアサーションです。 それはユーザー名を指定し、署名はその内部にあり、 そのIDによってアサーションを指し示します。 そしてすべてがあなたのブラウザ、つまり ユーザーを経由して行われます。 それをチェックするために、アプリは

正規化：すべてのバイトで合意するか、誰もログインできない

1:11 署名された正確なバイトを再構築します。 署名を切り出し、空白と属性の順序を正規化し、 結果をハッシュ化します。 それが正規化であり、両側が1バイトでも異なる場合、 誰もログインできません。 JSON Web Tokenは異なる方法で行います。 ヘッダー、ペイロード、署名がドットで区切られて並んでいます。 最初に切り出すものはありません。

2012年：チェッカーとリーダーが異なる要素を見る

1:32 ここが問題です。 署名をチェックするコードとユーザー名を読み取るコードは、 しばしば別々のものです。 2012年、「On Breaking Saml」という論文は、署名されたアサーションを読み取り側が無視する場所に移動させ、 読み取り側が見る場所に2つ目を置くことができることを示しました。 SalesforceとShibbolethは、これに引っかかった11社の中にいました。 2018年、Duoは、ユーザー名の中のコメントが一部のライブラリに名前の半分しか読み取らせず、

2018年と2025年：2つのパーサー、2つの異なる回答

1:55 その間も署名は有効であるということを示しました。 2025年、GitHubは、Ruby SAML内で2つのXMLパーサーが 同じドキュメントについて異なる意見を持っていることを発見しました。 同じバグ、新しい10年。 Trail of Bitsはそれをフラクタルと呼んでいます。なぜなら、ズームインするすべてのレベルに

なぜ壊れ続けるのか：ひどい設計のフラクタル

2:12 同じ欠陥があるからです。XMLに基づいて構築されており、署名はエンベロープ化されており、 実際のログインでは仕様の約10分の1しか使用されません。 そしてHacker Newsのトップリプライは購入者からのものです。 「SAMLのサポートがないなら、対応する製品を見つけることができます。」 両方とも真実であるということが問題です。 ですから、月曜日。まずOpenID Connectを出荷し、FlyとTailscaleはSAMLなしで

月曜日：まずOIDC、保守されたライブラリ、厳格な形状

2:31 企業に販売しています。 顧客がSAMLを強制する場合は、保守されたライブラリを使用し、常にパッチを適用し、 OktaやGoogleが送信するものと異なるメッセージは拒否してください。 独自の署名チェックは絶対に書かないでください。

結論、その仕組み：REVERT

2:43 結論、その仕組み。 REVERT。ほぼ25年間、決して死なない1つのバグクラス、 そして皆が同意する解決策は別のプロトコルです。 先週の土曜日にパスキーを分解しました。次に何を分解すべきかコメントで教えてください。 今日の差分は以上です。 Axrisiのニコールです。 責任を持ってマージしてください。

情報源

1. Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
2. Hacker News threadnews.ycombinator.com
3. Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
4. Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
5. GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog