Session SAML服务提供商在初始身份验证（vs OIDC）后如何理解身份？

我希望为第三方应用程序实现一个插件，使该应用程序能够被视为SAML服务提供商，这样我就可以将其集成到

下图描述了服务提供商（SP）和身份提供商（IdP）使用HTTP工件绑定（取自）时的SAML身份验证过程：

初始身份验证后，SP将受保护的资源返回给用户。我的问题涉及如何处理随后对受保护资源的请求

有了OIDC，浏览器将收到一个令牌，该令牌将被发送到SP进行后续请求。SP可以检查令牌并确认其完整性（假设已签名）和有效性，而无需进一步调用IdP来重新验证最终用户

使用SAML，如何实现相同的效果？我如何不必重复打电话给IdP检查身份

---

我想我可以使用会话，但我不明白如何确保这些信息在客户端内不被篡改（即SP如何不必依赖客户端提供的信息？）。SAML是否有某种令牌的概念，用户可以安全地存储该令牌（HTTP工件绑定明确限制用户查看来自IdP的响应）？

规范中没有定义最后一步之后会发生什么。您可以说它在形式上超出了SAML协议。甚至SP提供资源的最后一个协议形式化步骤本质上也是“自己动手”：

第3.4.5节（HTTP重定向绑定）：

收到SAML响应后，SAML请求者返回 对用户代理的任意HTTP响应

第3.5节（HTTP-POST绑定）：

收到SAML响应后，SAML请求者返回 对用户代理的任意HTTP响应

第3.6节（HTTP工件绑定）：

[你现在可能已经猜到了]

在最后一步中，大多数SP将在客户端上丢弃一个或多个cookie。其中一个Cookie将包含会话ID或更通用的指针，在发送回SP时可用于定位会话。SP随后的资源“授权”请求将通过让SP咨询此服务器端会话继续进行。会话通常会保存此用户/客户端的（已验证的）安全上下文

例如，Shibboleth（构建在OpenSAML之上）。cookie的内容由SP决定。有争议的是，通过本地存储等方式进行的基于令牌的身份验证比cookie更安全。有许多特定于用例/上下文/技术堆栈的因素会影响风险和相关威胁模型的评估

---

注意：AWS SSO不支持工件绑定。

\u使用OIDC，浏览器将接收令牌，并将其发送到SP以供后续请求。\u事实并非如此，怎么会呢？对于OIDC与auth/authz的典型集成，一旦用户进行了身份验证，JWT通常会通过某种方式返回（cookie或本地存储，并考虑XSS/CSRF）。随后对受保护资源的请求将包含该JWT。SP将检查令牌的有效性，并在JWT有效的情况下提供受保护的资源。根据OIDC流（），浏览器可能看不到ID令牌（即标准化JWT），只有OIDC客户端可以检索它。啊，是的，谢谢，说得好。