我知道在服务器端呈现的spa中有以下令牌管理模式:
注释:这里的frontend server是指承载SPA并执行SSR的服务器。
通过前端服务器代理singup/sign - in/sign - out/refresh-token请求
描述所有涉及获得令牌响应的请求将通过前端服务器完成(而不是客户端直接向后端服务器发出ajax请求)。前端服务器仅通过端点向客户端公开访问令牌，以便它可以直接向服务器发出其他类型的请求。
Implementation前端服务器可以在httponlycookie中设置令牌以实现无状态实现。并通过调用客户机能够获得访问令牌的端点仅公开访问令牌。
下行访问令牌在XSS攻击的情况下会被泄露。
通过前端服务器代理所有请求到后端API
描述客户端通过前端服务器向后端发出所有请求。客户端不直接向后端服务器发送请求。
实现前端服务器可以在httponlycookie中设置令牌，实现无状态。
下行前端服务器可能成为瓶颈。
我提到的解决方案是正确的吗?上述解决方案还有什么缺点吗?在SSRed spa中有其他令牌管理的解决方案和模式吗?
在浏览器中避免令牌通常被视为更安全的选择。如OAuth for Browser Based Apps中所述。并使用最新的最强的cookie。
这样做的一个选项是仅从兄弟域(例如https://api.example.com)为位于https://www.example.com的SPA发出HTTP cookie。这为您提供了额外的部署选项，例如:
-
将静态内容部署到内容分发网络，以获得最佳的全球web性能
-
将cookie发布组件部署到API域，例如解析到Kubernetes集群
在cookie术语中，这些域位于同一站点，因此cookie是第一方且可靠地工作。cookie只能通过Ajax请求来设置，所以前端也有很好的可用性控制。
当web和API问题严格分离时，这个选项往往工作得最好，例如服务器呈现的内容没有安全数据。在这种情况下，cookie只需要用于API请求。
所以不确定它是否适合您的架构，但了解一下很有趣。它有时可以用于启用web开发人员可以在开发过程中完全外部化安全性的设置。