我有一个Angular应用程序，它使用Angular -auth-oidc-client与KeyCloak服务器集成
我使用PKCE流并从Keycloak服务器(OIDC提供程序)获得id令牌、访问令牌和刷新令牌。我不需要刷新令牌，但Keycloak服务器似乎总是返回它，即使scope不使用"offline_access"
默认情况下，OAuth库将所有令牌存储在会话存储中。我已经编写了一个自定义存储来忽略刷新令牌，并且不将它们存储在会话存储中。
我在网上读到会话存储不是完全安全的存储，存储的XSS攻击可以检索令牌。然而，存储XSS的缓解方法是使用标准框架，比如我正在使用的Angular。
假设存储的XSS漏洞几乎不可能存在，那么我使用会话存储中的访问令牌来调用后端api的上述解决方案是否安全?
目前spa的最佳做法
当使用访问令牌时，有更多的攻击向量和未知，目前的最佳实践是使用Backend for Frontend，以便在浏览器中只使用HTTP Only SameSite=strictcookie。
也可以通过实用API发出cookie，以避免影响您的整体SPA架构。在security，我们的SPA最佳实践对此有进一步的信息，尽管这是一个棘手的流程。
还有一个白皮书的链接，更深入地讨论了威胁。在某种程度上，您选择的解决方案还取决于您的数据的价值有多高。对于中等和高安全性的数据解决方案，目前首选仅cookie解决方案。
多个spa和单点登录
SSO是身份提供者会话cookie的属性，也是应用程序是否使用OpenID连接参数，如prompt=login和max_age。因此，多个spa仍然可以使用BFF解决方案实现单点登录，每个应用程序被颁发不同的令牌。
多个spa在调用API时必须使用隔离的cookie，因此使用不同的API路由。这增加了复杂性，所以我理解这些担忧。我还喜欢老式的仅使用Javascript的解决方案(如oidc-client)的简单性。
<<p>攻击向量/strong>这些包括通过fetch API的猴子补丁捕获飞往API的令牌，攻击者旋转一个隐藏的iframe来获取令牌，或者浏览器扩展的拦截动作。
如果令牌被截获，它们可能会被发送出浏览器。内容安全策略应该降低这种风险，但用户或插件可以禁用它们。这个视频讨论了威胁，非常有趣。
这是最大的因素之一——如果你曾经必须向客户、利益相关者或PEN测试人员解释你的安全性。如果你遵循BCP，这些对话就会更容易。否则，在某些部门，你可能会面临难题。