我有一个使用 angular-auth-oidc-client 与 KeyCloak 服务器集成的 Angular 应用程序
我使用 PKCE 流程并从 Keycloak 服务器（OIDC 提供程序）获取 id 令牌、访问令牌和刷新令牌。我不需要刷新令牌，但 Keycloak 服务器似乎总是返回它，即使范围不使用“offline_access”。
默认情况下，OAuth 库将所有令牌存储在会话存储中。我编写了一个自定义存储来忽略刷新令牌，而不是将它们存储在会话存储中。
我在互联网上读到会话存储不是完全安全的存储，存储的 XSS 攻击可以检索令牌。然而，Stored XSS 的缓解措施是使用标准框架，如我正在使用的 Angular。
假设存储型 XSS 漏洞几乎是不可能的情况，上述解决方案是否安全，其中我使用会话存储中的访问令牌来调用我的后端 API。
SPA 的当前最佳实践
使用访问令牌时有更多的攻击向量和未知数，当前的最佳实践是使用 aBackend for Frontend以便HTTP Only SameSite=strict在浏览器中只使用 cookie。
也可以通过实用程序 API 发出 cookie，以避免影响您的整体 SPA 架构。在 Curity，我们的SPA 最佳实践对此有更多信息，尽管这是一个棘手的流程。
还有一个指向更深入讨论威胁的白皮书的链接。在某种程度上，您选择的解决方案将取决于您的数据的价值。对于中高安全性数据解决方案，目前首选仅 cookie 解决方案。
多个 SPA 和单点登录
SSO 是身份提供者会话 cookie 的属性，也是应用程序是否使用 OpenID Connect 参数，例如prompt=login和max_age。因此，多个 SPA 仍然可以使用 BFF 解决方案实现 SSO，每个应用程序都被发行不同的令牌。
多个 SPA 在调用 API 时必须使用隔离的 cookie，因此需要使用不同的 API 路由。这增加了复杂性，所以我理解这些担忧。我也喜欢oidc-client等较旧的纯 Javascript 解决方案的简单性。
攻击向量
其中包括通过 fetch API 的猴子补丁捕获飞行中的令牌、攻击者旋转获取令牌的隐藏 iframe 或浏览器扩展的拦截操作。
如果令牌以某种方式被拦截，它们可能会被发送出浏览器。内容安全策略应该降低这种风险，但用户或插件可以禁用它们。该视频讨论了威胁并且非常有趣。
洞察力
这是最大的因素之一——如果您必须向客户、利益相关者或 PEN 测试人员解释您的安全性。如果您遵循 BCP，这些对话会更容易。否则，在某些领域，您可能会面临棘手的问题。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句