# SAML，內部構造：信件中的簽名

Published: 2026-09-24

SAML 讓您登入幾乎所有工作應用程式，其簽名位於所簽署的 XML 內部。內部構造：應用程式、瀏覽器和身分提供者之間的登入過程，斷言的樣子，為何正規化必須就每個位元組達成一致，以及為何相同的錯誤類別從 2012 年到 2025 年一直重現。受 Trail of Bits 的「SAML：壞設計的碎形」(在 Hacker News 上獲得 312 分) 啟發。

Canonical: https://thedailydiff.dev/zh-HK/video/2026-09-24-saml-under-the-hood/

## 本影片涵蓋的內容

- SAML：從內部自行簽署的登入
- 2002年：四種XML格式，一個委員會，一個完整產業
- 登入流程：應用程式 → 身分提供者 → 透過瀏覽器返回
- 斷言：簽名位於它所簽署的內容內部
- 正規化：就每個位元組達成一致，否則無人能登入

## 章節

- 0:00 SAML：從內部自行簽署的登入
- 0:34 2002年：四種XML格式，一個委員會，一個完整產業
- 0:46 登入流程：應用程式 → 身分提供者 → 透過瀏覽器返回
- 0:59 斷言：簽名位於它所簽署的內容內部
- 1:10 正規化：就每個位元組達成一致，否則無人能登入
- 1:32 2012年：檢查器和讀取器查看不同的元素
- 1:51 2018年和2025年：兩個解析器，兩個不同的答案
- 2:08 為何它不斷出錯：壞設計的碎形
- 2:27 星期一：OIDC優先，一個維護良好的程式庫，嚴格的格式
- 2:43 內部構造裁決：REVERT

## 翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。

### SAML：從內部自行簽署的登入

0:00 SAML 是讓您登入幾乎所有工作應用程式的 XML 文件， 它的簽名就存在於它所簽署的文件內部， 就像公證人在他密封的信封裡面釘上他的印章一樣。 委員會撰寫完成十年後，研究人員測試了十四個 SAML 框架。其中十一個失效。 而本週 Trail of Bits 的一篇帖子稱其為壞設計的碎形，該帖子登上了 Hacker News 的頭版。 三分鐘內：登入流程如何運作，簽名藏在哪裡，

0:27 以及為何大家一致同意的解決方案是使用不同的協定。 這裡是《The Daily Diff》的內部解析。

### 2002年：四種XML格式，一個委員會，一個完整產業

0:34 二千零二年。 OASIS 的一個安全委員會將四種供應商的 XML 格式合併為一種。 大學率先採用，然後 Okta 在此基礎上建立公司， 這是一個委員會文件轉化為收入的最快速度。 您打開應用程式。

### 登入流程：應用程式 → 身分提供者 → 透過瀏覽器返回

0:46 它不知道您是誰，所以它將您的瀏覽器彈到身份提供者， 例如您公司的 Okta。 您在那裡登入。 Okta 將一份已簽署的 XML 文件交給您的瀏覽器，說明您是誰， 然後瀏覽器將其回傳。

### 斷言：簽名位於它所簽署的內容內部

0:59 這份文件就是斷言 (assertion)。 它指明了用戶，而簽名就在其內部， 透過其 ID 指回斷言。 整個過程都透過您的瀏覽器進行，也就是說， 透過用戶。 為了檢查它，應用程式

### 正規化：就每個位元組達成一致，否則無人能登入

1:11 重新建構簽名時的確切位元組。 它將簽名切除，標準化空白和屬性 順序，然後哈希處理結果。 這就是正規化 (canonicalization)，如果雙方差一個位元組都無法達成一致， 就沒有人能登入。 JSON Web Token 的做法不同。 標頭、負載和簽名並排，中間以點分隔。 無需先切除任何東西。

### 2012年：檢查器和讀取器查看不同的元素

1:32 問題就在這裡。 檢查簽名的程式碼和讀取用戶名的程式碼 通常是兩個不同的部分。 在 2012 年，一篇名為《On Breaking Saml》的論文展示了你可以將 已簽署的斷言移到讀取器忽略的位置，並在讀取器查看的位置放置第二個斷言 Salesforce 和 Shibboleth 是其中十一個受影響的公司。 2018 年，Duo 展示了一個使用者名稱中的註釋可以使某些

### 2018年和2025年：兩個解析器，兩個不同的答案

1:55 程式庫只讀取一半名稱，而簽名仍然通過檢查。 2025 年，GitHub 發現在 Ruby SAML 中兩個 XML 解析器 對同一份文件存在分歧。 同樣的錯誤，新的十年。 Trail of Bits 稱之為碎形，因為你深入的每一個層次都存在

### 為何它不斷出錯：壞設計的碎形

2:12 同樣的缺陷。它建立在 XML 上，簽名是內嵌的， 而實際的登入可能只使用了規範的十分之一。 Hacker News 上的熱門回覆來自買家。 如果您不支援 SAML，我可以找到支援的產品。 兩者都屬實，這就是問題所在。 所以，週一。首先發布 OpenID Connect，Fly 和 Tailscale 將產品賣給

### 星期一：OIDC優先，一個維護良好的程式庫，嚴格的格式

2:31 完全沒有 SAML 的企業。 如果客戶強制要求，請使用維護良好的程式庫，保持更新， 並拒絕那些看起來不像 Okta 或 Google 發送的訊息。 切勿自行編寫簽名檢查。

### 內部構造裁決：REVERT

2:43 內部構造裁決。 REVERT。將近二十五年，一個從未消失的錯誤類別， 而大家一致同意的解決方案是使用不同的協定。 上週六我拆解了通行密匙 (passkeys)，所以請在評論中告訴我接下來要拆解什麼。 這就是今天的不同之處。 我是 Axrisi 的 Niko。 負責任地合併。

## 來源

- [Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)](https://blog.trailofbits.com/2026/09/21/saml-a-fractal-of-bad-design/) — blog.trailofbits.com
- [Hacker News thread](https://news.ycombinator.com/item?id=49806335) — news.ycombinator.com
- [Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012](https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/somorovsky) — www.usenix.org
- [Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445](https://www.kb.cert.org/vuls/id/475445) — www.kb.cert.org
- [GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)](https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials/) — github.blog