我们有一个客户端应用程序，希望通过OIDC启用SSO。客户端应用程序是带有专用后端API的SPA。当前，身份验证是通过Cookie来实现的，并且根据Auth_Cookie的用户在后端实施授权。 OIDC身份验证完成后，我们希望继续利用这些现有的基于本地cookie的代码/逻辑，这也避免了将令牌存储在SPA中的需求。
完成Auth Code PKCE流后，前端SPA将直接从OP的/token端点接收ID_Token和Access_Token。要从ID / Access_Token到Auth_Cookie，可以采用以下方法：
/authenticate）由于ID_Token仅用于客户端应用程序（在此情况下为前端SPA），因此我假设它在此序列中不起作用（尽管从逻辑上讲，您会认为对后端应用程序的调用API的/authenticate端点应提供类似于凭证的内容，例如ID_Token）。
以上方法是否有意义，并且是否存在任何安全问题/担忧？是否有其他方法/更好的方法可以将前端OIDC身份验证上下文实质上转换为cookie？
任何见解或帮助将不胜感激。谢谢。
答案 0 :(得分：0)
我认为，使您的后端进程进行auth重定向会更容易-使它成为OAuth2客户端而不是SPA。您的SPA不需要令牌，也不需要将访问令牌转移到后端。后端处理程序将接收身份验证代码，它将获取令牌并创建身份验证cookie（具有所有安全参数）。
如果您需要将SPA保留为OAuth2客户端，那么您提出的解决方案可能很好。
答案 1 :(得分：0)
由于谢尔曼（Sherman）进行了有趣的讨论，您使我意识到我做的事情不太正确，所以我更新了一些内容。
选项1-Cookie
这很有道理，尤其是在您不需要跨域功能的情况下。完全承诺不使用cookie可能也需要大量工作。
选项2-带有存储在内存中的令牌的无饼干
有可能构建一个完全没有cookie的SPA，并且仍然可以处理可用性问题，例如用户无需重新登录即可刷新页面。它是在授权服务器上的先决条件，但该服务器必须正确支持hint = none参数。
选项3-HTML5会话存储中存储的代币无法烹饪
正如我们所讨论的，很多人并不认为这是安全的，因此，如果可能的话，最好避免使用。如果您的授权服务器不支持提示符= none，则可以考虑使用它。