将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时都会传递身份验证代码？弹簧代码是否每次都调用/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问题。