问题描述
将我的应用程序之一与 SAML 2.0 单点登录集成。为此使用 Okta 提供程序。在 okta 中成功验证后，我收到了 base64 编码的“SAML 响应令牌”并重定向回我的应用程序。在这个令牌中，我看到了我需要的所有用户详细信息，但我的问题来了。我是否需要进一步验证该响应，还是应该相信我收到的信息？考虑到这个令牌也包含签名？
我的安全想法是再次联系 Okta 并验证这是否真的由 Okta 发布。不确定这是否可能。
使用 NodeJS 进行验证。
解决方法
如果您不想在后端进行适当的令牌验证（不要责怪您，这很痛苦），请切换到 OIDC。这更适合前端的身份验证和授权。
但是，如果 SAML 响应发送到后端并由后端处理，并且一些其他令牌正在转发到您的应用程序，那么您应该评估验证该令牌的要求是什么。
您的问题中不清楚的是我们谈论的是用户流程中的哪个位置，因此我的答案的评论数量。
,如果 SAML 响应令牌是指根据 Web 浏览器被动 SSO 配置文件发布的 samlp:Response，则响应包含断言并且断言被签名由身份提供者（此外，整个响应也可以签名）。
始终验证响应签名是一项关键的安全要求。 SAML specs，第 4.1.4.3 节
中提到了这一点其原因如下：在 Web 浏览器 SSO 配置文件中，身份提供者在网页中返回令牌，该网页包含一个带有 SAMLResponse 和 RelayState 字段的简单表单以及一个位仅将此表单自动发布到您的应用程序的代码。从技术上讲，这意味着令牌在短时间内由用户的网络浏览器控制，而此时令牌可以被更改（或伪造）。
因此，协议安全在很大程度上依赖于通过加密签名实现的令牌完整性 - 它只是应用于 SAML 的普通旧 XMLDSig 签名。
作为令牌接收者，您的目标不仅是验证签名，还要检查签名的证书，并将其与您期望从受信任的提供者（或受信任的提供者的证书列表）获得的证书进行比较。
跳过此步骤会使您的应用程序易受攻击：
-
跳过验证意味着用户可以更改对断言的令牌（添加/创建/删除）声明，签名验证会失败，但您可以跳过它
-
跳过与已知证书匹配的证书意味着用户可以伪造自己的断言，使用虚拟证书对其进行签名并呈现给您的应用程序。签名验证步骤会成功，但您不会意识到使用虚拟证书对断言进行签名