将id_token传递给浏览器代码是不安全的吗？

Question

我一直在深入挖掘OAuth2 / OpenID Connect（OIDC），在很多方面我感觉更聪明，但在很多方面，我担心一个简单的错误会让我感到脆弱。我正在构建超标准的商业应用程序。所以是时候问路了：

• 平台：Pivotal Cloud Foundry / UAA
• 后端：Spring Boot 1.5.x（现在看2.0）
• 前端：React SPA
• OAuth2 ：使用openid范围
验证代码授予

我收到id_token，access_token和refresh_token

我有一百万个问题，但让我们从基础开始：

1. 是否可以使用id_token并将其发送到浏览器中的反应代码并将其存储在会话存储中？否则UI究竟想知道有关登录人员的信息？

2. 如果我有id_token，我还关心/userinfo端点吗？我的猜测是否定的。

3. 每次UI调用api时都会传递身份验证码？ Spring代码是否每次都调用/oauth/token？ Spring代码应该（或者是否）缓存auth代码和返回的令牌之间的关系？

Answer 1

您只询问openid范围，那么为什么需要访问权限和刷新令牌？并且由于您希望React应用程序使用ID令牌，我建议您使用Implicit流程 - 将ID令牌直接提供给您的前端。

1. 您可以将令牌保留在SessionStorage中。
2. ID令牌可能包含您需要的所有信息，因此如果/userinfo端点没有提供您想要的任何其他内容，则可以忽略它。
3. 出于安全原因，验证码只能使用一次。所以在获得令牌之后保持它是没有意义的。如果要保持后端API无状态（无会话），可以使用访问令牌。然后，可以在auth服务器上配置特定于后端的范围，或仅使用/userinfo端点来获取有关用户的信息。或者，如果您希望将前端和后端视为一个OAuth2客户端（相同的ID令牌受众），并且您在后端需要用户身份，则可以使用ID令牌。

Answer 2

SPA的推荐流程为implicit，并且使用oidc-client-js库是有意义的。在此流程中，access_token将直接返回给客户端，而无需其他授权代码步骤。没有发出refresh_token。

在此拓扑中，令牌存储在sessionStorage的客户端（默认情况下，但这是可插入的），并且您通过在Authorization标头中传递access_token（通常）来向后端发出请求。令牌更新不是通过刷新令牌完成的，而是通过后台静默授权端点调用自动完成的。这种方法的缺点是，如果您的应用程序通过XSS受到攻击，那么攻击者可立即使用您的令牌。

但是，如果您更乐意使用服务器端流程（具有表单发布响应类型的混合）和（仅https）cookie身份验证，那么您可以。客户端代码只需要实现某种CSRF缓解，但根本不需要了解OpenID Connect问题。