由 dawei 这个问题并不是SAML独有的，签名的JWT和其他SSO的使用(比如OIDC中的使用)也可能遇到类似的问题，即缺少令牌验证。
SAML是如何工作的?
从较高的层次上讲，SAML是一种登录用户的方式，它使用两个系统之间的浏览器内部通信，否则它们之间不能相互通信。当用户想要登录到他们最喜欢的SaaS时，SaaS应用程序(SP或服务提供商)会将一些关于登录请求的数据发送到你的IDP。这包括诸如惟一请求ID和数据(如你试图访问的原始页面)之类的内容。理论上，身份验证请求可以指定IDP应该返回哪种类型的用户名和名称之类的字段，但实际上这会被忽略。这些请求也可以签名，但实际上在SP旋转其密钥时，大多数情况都会使事情中断。安全性几乎没有好处，因为在任何现代系统中，SAML交换都是通过TLS进行的。
一旦你的IDP接收到身份验证请求，IDP将验证你是否已登录(可能是密码、可能是客户端证书)，然后签署一个断言。断言是SP将验证并用于登录你的内容。然后，你的IDP将此断言发送回SP。SP验证密码签名，验证该断言是否应该发送到特定的SP，并提取相关的用户名和其他字段。现在，你可以看所有你想看的图片了!
那个签名秘钥听起来很吓人!你的本能可能是不惜一切代价保护该密钥。密钥值得保护，但是对你的SAML IDP安全最大的可信威胁不是拥有你的SAML服务器的攻击者。
攻击SAML的方法
攻击SAML的方法有很多!尽管独特的签名密钥可以解决其中的一些问题，但这并不是万能的。
受众限制问题(Audience restriction issue)
这是我在这篇文章中关注的问题，稍后我将更详细地讨论它。不出意料，惟一签名密钥解决了这类问题。
IDP签名密钥被盗：确实，能够访问你的IDP的人可以获得签名密钥的副本，并以任何人的身份登录到与你集成的任何网站。如果这是你所关心的威胁，则仅提供签名预言的硬件支持的密钥是正确的防御措施。
XML和XML安全库：如果可以的话，你应该使用一个内存安全的库。也就是说，这对第三方的断言验证没有实际影响，而且如果使用惟一签名密钥，你的安全状态也不会改变。