SAML 解碼器
從 Base64 編碼的 XML 解碼 SAML 斷言。所有處理均在您的瀏覽器中完成，確保最高安全性與隱私。
解碼後的 XML
解析後的 SAML 資料
簽發者
—
名稱ID
—
簽發時間
—
受眾
—
生效時間
—
到期時間
—
驗證情境類別
—
屬性
未找到屬性
| 屬性名稱 | 值 |
|---|
如何使用 SAML 解碼器
貼上 SAML 資料
從您的 SAML 追蹤記錄或網路請求中複製 Base64 編碼的 SAML Response 或 Assertion
自動解碼
本工具自動解碼 Base64 並偵測 deflate 壓縮以還原 XML
檢視詳情
檢視解碼後的 XML 與擷取的欄位，包括簽發者、NameID 與屬性
什麼是 SAML？
安全性聲明標記語言（SAML）是一種基於 XML 的開放標準，用於在各方之間交換驗證與授權資料，特別是在身分識別提供者（IdP）與服務提供者（SP）之間。SAML 斷言通常以 Base64 編碼，在透過 HTTP 重新導向綁定傳輸時可能會進行 deflate 壓縮。
SSO 身份驗證
SAML 實現單一登入，使用者只需驗證一次即可存取多個服務
基於 XML 的斷言
SAML 使用 XML 斷言在各方之間傳遞身份驗證和授權聲明
安全綁定
SAML 支援 HTTP Redirect、POST 和 Artifact 綁定，實現安全權杖交換
常見問題
本工具支援 Base64 編碼的 SAML Response 與 Assertion XML，常見於 SAML 重新導向與 POST 綁定中。它也會自動偵測並解壓縮 deflate 壓縮的 SAML 請求。
是的。所有處理完全在您的瀏覽器中進行。您的 SAML 憑證不會被傳送到任何伺服器。沒有任何資料會離開您的裝置。
透過 HTTP 重新導向傳送的 SAML 請求通常會在 Base64 編碼之前進行 deflate 壓縮，以縮短 URL 長度。本工具會自動偵測並解壓縮此類資料。
請求（request）是服務提供者（SP）送出、用來要求身分提供者（IdP）驗證使用者的 samlp:AuthnRequest；回應（response）則是傳回的 samlp:Response，其中帶有包含驗證陳述與屬性的 saml:Assertion。兩者皆以 URL 編碼傳送（Redirect binding），或放在 HTML 表單 POST 內（POST binding）。本工具兩種方向都能解碼。
那是 SP 附加在請求上的一個不透明字串，IdP 必須原封不動地隨回應傳回——通常是登入後要重新導向的網址。SAML bindings 規格建議長度保持在 80 位元組以內，而且 IdP 不會對它做任何解讀。當 SSO 落到錯誤的頁面時，遺失或損毀的 RelayState 往往是頭號嫌疑犯。
在 HTTP-Redirect binding 中，XML 會先以 raw-Deflate 壓縮，再經 Base64，最後做 URL 編碼——這是規範要求的三個步驟。把 URL 編碼後的值交給本工具：如果解開後是以 < 開頭的標記，代表有壓縮；如果一開始就是 <?xml 或 <saml，則代表沒有。POST binding 的訊息只做 Base64，不含 Deflate。
時鐘偏差——當 SP 與 IdP 的時鐘相差超過允許的誤差範圍時，簽章驗證就會失敗；受眾不符——斷言中的 audienceRestriction 未包含 SP 的 entity ID；以及回應過期（NotOnOrAfter）。也很常見的還有：缺少 RelayState，以及 SP 要求簽章但斷言未簽署。本工具顯示的解碼欄位可讓您直接檢查上述每一項。
可以——解碼不等於驗證。斷言的 XML 任何人都能讀取；其中的簽章保障的是完整性，而非機密性。沒有 IdP 的公開憑證，您無法證明斷言是可信且未被竄改的。請謹慎處理任何解碼後的內容：斷言通常包含電子郵件地址、群組與權限資訊。