企業の認証基盤では今もSAMLが広く使われています。古くからあるからこそ、多少の面倒は「運用で吸収するもの」と見なされがちですが、Trail of Bitsはそこに強く異議を唱えています。この記事が面白いのは、単に「SAMLには脆弱性がある」と言うのではなく、プロトコルの土台そのものが複雑すぎて、問題が何度直されても別の形で顔を出す、と整理している点です。しかも、代替としてOpenID Connect（OIDC）へ移るべきだとはっきり主張しています。
元記事の筆者は、SAMLを「SSO業界を生んだが、もう寿命を迎えている認証プロトコル」と位置づけています。SAMLは2002年にOASISのSecurity Services Technical Committeeで作られたXMLベースの仕様で、Web 2.0期に増えた多くのSaaSを、ひとつの認証で使い回すための基盤になりました。大学や研究機関ではCAS、Shibboleth、MicrosoftのADFS、simpleSAMLphpのような実装が広がり、やがてPing Identity、OneLogin、Okta、Duo Securityといった商用サービスもこの土台の上で成長した、というのが筆者の整理です。
ただし、その成功の裏でSAMLはどんどん重くなった、と筆者は見ています。まず前提として、SAMLはXMLの上に作られています。XML自体が複雑で、タグ、属性、名前空間、CDATA、DOCTYPEなど扱う要素が多く、SAMLライブラリはSAML本体にたどり着く前にXXEやbillion laughs、DTD retrieval、XPath/XQuery/XInclude/XSLT/CDATA injectionといった古典的なXML由来の問題をさばかなければなりません。筆者はこの複雑さそのものを「fractral of bad design」と呼んでいます。
中でも大きな問題として挙げられているのが、canonicalization、enveloped signatures、そしてsignature wrapping攻撃です。canonicalizationは、XMLの見た目の揺れを正規化して、送信側と検証側で同じバイト列として扱えるようにする処理ですが、ここが少しでもずれると署名検証が崩れます。筆者は、2018年のKelby LudwigによるXML comment bypassがこの問題の延長線上にあると述べています。さらに、署名を検証対象のデータの中に埋め込むSAMLの設計は、あとからデータをいじる余地を増やし、parser differentialやround-trip bugを呼び込みやすいと指摘します。JWTのように署名をペイロードから切り離した方式と比べると、かなり扱いにくいというわけです。
また、SAMLは仕様が巨大なのに、実運用で使われているのはその一部にすぎないとも書かれています。SOAPやartifact bindingのような要素は、現場ではほとんど使われないのに仕様には残り続ける。筆者はこれを「kitchen-sink design」と呼び、99%の実装は仕様の90%を避けているのではないかと見ています。最後に、SAMLは作られた時代が古く、HTTP+TLSを前提にした現代のWebにうまく馴染めていないとも述べます。OIDCはHTTPに寄せ、通信経路やバックチャネルの考え方も整理されていて、結果としてシンプルで進化しやすい。だからSAMLは退役し、OIDCに移るべきだ、というのが記事全体の主張です。
この文章でいちばん強く残るのは、SAMLの問題を個別の脆弱性集としてではなく、複雑さの帰結として見ている点です。ここは重要だと思います。安全な設計は、あとから丁寧な実装を積み上げればどうにかなる、という発想では限界がある。SAMLは仕様、XML、署名、正規化、パーサの挙動が全部絡み合っていて、ひとつ直しても別の層で破綻しやすい。Trail of Bitsが「fractal」と言うのは誇張ではなく、同じ種類の問題が縮尺を変えて何度も現れるからでしょう。
特に認証の世界では、少しの解釈違いがそのまま「別人としてログインできる」に直結します。通常のWebバグなら壊れたページで済むことも、認証では致命傷になる。だからこそ、canonicalizationのような「見た目を同じにするための補助処理」が中心機能の一部になってしまう設計は危ないと思います。人間にとっての柔軟さが、機械にとっては曖昧さになるからです。SAMLはこの曖昧さを、長年の運用でなんとか埋めてきたように見えますが、埋めたのであって消したわけではない、というのが実態ではないでしょうか。
筆者はSAMLを「退場すべき」と言いますが、現実にはすぐには消えません。ここは記事の外側にある最大の論点だと思います。SAMLが残る理由は、技術的優位というより、企業の既存システム、契約、監査、運用手順、社内ポータル、委託先との接続が全部SAML前提で固まっているからです。認証基盤は一度入ると10年単位で残るので、いま安全な代替があるかどうかより、当面止まらないことのほうが意思決定に効いてしまう。
だからこそ、Trail of Bitsの「OIDCへ移れ」というメッセージは、純粋な技術論というより、移行コストを払ってでも今の複雑さを減らすべきだという経営判断への提案に近いと感じます。しかも、攻撃者は昔の論点を忘れてくれない。signature wrapping のような古い話題が、2025年まで新しいバリエーションとして出てきているのは、問題が解決したのではなく、別の実装で再発している証拠です。技術負債というより、認証の世界にこびりついた構造的負債に見えます。
元記事はOIDCをかなりはっきり推していますが、ここは「新しいから優れている」という単純な話ではありません。むしろ、OIDCは責務の切り分けがうまい。HTTPを前提にし、TLSに通信の安全性を任せ、認証プロトコル側は必要な情報に絞る。署名もJSONベースで扱いやすい形に寄せる。つまり、認証メッセージの中に全部を詰め込まない設計です。
この差は、単に仕様書が読みやすいかどうかではなく、将来の保守に効いてきます。仕様が軽いと、実装差分が小さくなる。実装差分が小さいと、パーサの解釈違いが減る。解釈違いが減れば、攻撃者がつけ込める余地も減る。Trail of Bitsの記事を読んで感じるのは、SAMLの失敗は「XMLだから悪い」で片づくものではなく、複雑さを許したまま長く使い続けたことの失敗でもある、ということです。OIDCに移るべきだという提案は、流行を追う話ではなく、複雑さをどこで止めるかという設計哲学の話として受け取るのが自然だと思います。
