Oauth 2 流程：AWS Cognito 的 id_token 是否应该传递给浏览器进行会话管理？答案

【问题标题】：Oauth 2 flow : Should AWS Cognito's id_token be passed to the browser for session management?Oauth 2 流程：AWS Cognito 的 id_token 是否应该传递给浏览器进行会话管理？
【发布时间】：2020-05-24 12:04:50
【问题描述】：

我正在创建一个应用程序，其中：

我有一个 REST API - /hello
用户只有在登录后才能访问此 API。

为此，我决定使用 AWS Cognito 并实施 Oauth 2.0 流程。

现在，当用户尝试访问 /hello 时，他们会被重定向到 AWS Cognito 登录页面。用户登录后，我的服务器端应用程序（包含 REST API /hello）可以从 AWS Cognito 获取 id_token 和 access_token。

我是否应该将此 id_token 传递给浏览器，并要求浏览器在访问 /hello REST API 时发送它？这是否有任何安全隐患？这是正确的方法吗？

或者，在用户通过身份验证后，我是否应该创建一个由我自己的自定义密钥签名的新 id_token，然后将其发送到浏览器？用户在尝试访问 /hello REST API 时会将其发回。然后，我将使用我的自定义密钥验证 id_token 是否有效。

id_token 的目的是验证用户的会话是否有效并且没有过期。 id_token 是否应该用于会话管理？

【问题讨论】：

标签： security spring-security oauth-2.0 amazon-cognito

【解决方案1】：

因此，我们的目标是避免在您的 React Web UI 中使用 cookie，而是使用无状态后端的令牌。我完全同意这个目标。

选项 1

将令牌从 Web 后端传递到 UI，UI 可以使用它们来维护客户端会话。这需要一个通过 Ajax 调用的 Spring 端点，并且需要通过 cookie 保护它。否则，攻击者可以调用该端点并获取令牌。

选项 2

通过oidc client library 在您的 React 应用程序中进行 OAuth 登录处理，而不是在 Spring Web 后端中，这样您的 UI 就是一个纯无 cookie 的 SPA。仅将 Spring 用作 OAuth 安全资源服务器。对 HTML / JS 文件使用静态内容托管，可能通过 AWS Cloudfront。

我的解决方案

如果对选项 2 感兴趣，我有一个演示 React 应用程序，它可以像这样工作并连接到 Cognito。您可以通过我的Quick Start Page 自行运行。

这里是SPA OAuth Code。同时我的Spring Sample 只作为一个Rest API，不做任何网络登录处理。

【讨论】：

感谢您的回答，但它没有回答我的问题：“我应该将此 id_token 传递给浏览器吗？”。我知道客户端应用程序使用访问令牌来访问资源服务器上的资源。
通常 id 令牌直接传递给浏览器（对于 SPA） - 如果使用在服务器端运行安全代码的 Web 应用程序，则在服务器端处理。无论哪种方式，代码通常都是由库为您完成的。如果您让我知道您正在使用的技术堆栈，我可以提供更量身定制的答案。
出于兴趣，是否有特定于 AWS 的东西建议将 id 令牌发送到资源服务器？这样做不是标准的，但有时供应商需要这种类型的东西，这可能会增加您的应用程序的复杂性。我尝试只使用基于标准的行为。
我在后端使用 Spring 安全性，在前端使用 React 作为技术堆栈。因此，一旦用户在 AWS Cognito 上通过身份验证，我就需要一些东西来维护会话。默认情况下，Spring 为此使用 JSESSION_ID cookie。关键是如果我们想要无状态会话，那么我们可以将 AWS Cognito 发送的 id_token 发送到浏览器。
同样，问题不在于将 id_token 发送到资源服务器。在 Oauth 2.0 或 OIDC 流程中，访问令牌被发送到资源服务器。问题是我应该将 AWS Cognito 生成的 id_token 传递给浏览器吗？我可以从您的评论中得出的答案是“是的，您可以”。