security - 如果 OpenID Connect id_token 和 access_token 标记为仅 HTTP，我是否可以将其安全地存储在 cookie 中？

Question

我正在将旧应用程序(ASP.NET MVC 4 应用程序)与 OpenID Connect 集成。从 OIDC 提供商处获取 id_token 和 access_token 后，我需要存储它们。在典型的方式中，它们必须从客户端“通过线路”发送到服务器端，因为服务器端必须处理 id_token 以确定哪个用户发出了请求。我的应用程序不处理 access_token。它只是存储在我的应用程序中，直到我需要向需要 JWT 承载身份验证的 API 发出请求为止。

我认为 id_token 和 access_token 是从客户端和服务器以任何一种方式发送的 - 无论是 header 还是 cookie。如果 id_token 和 access_token 标记为仅 HTTP，我可以将 id_token 和 access_token 安全地存储在 cookie 中吗？

编辑: 我应该添加更多有关我的场景的信息。

1) 我的应用程序始终使用 HTTPS，并且所有 cookie 都标记为安全。这消除了 MITM(中间人)漏洞

2) 每个 PUT、POST 和 DELETE 请求都使用 ASP.NET 的防伪造 token 类。这可以防止 XSRF。

3) 所有输入均使用 ASP.NET 库进行转义和清理，从而消除了 XSS 漏洞。

4) 包含 id_token 的 cookie 将被标记为仅 http，从而消除了从客户端读取和访问 cookie 的能力。

Answer 1

您可能不应该将 token 存储在 cookie 中。理想情况下，访问 token 将存储在客户端的内存中。这样它们就不会随请求自动发送到服务器，这就是 cookie 存在风险的原因。其他任何地方都可能让您面临潜在的漏洞。

RFC 6819标题为“OAuth 2.0 威胁模型和安全注意事项”的规范涉及 OAuth token 周围的风险和漏洞。具体来说，我建议阅读以下部分:

• 4.1.3. Threat: Obtaining Access Tokens
• 4.4.2.2. Threat: Access Token Leak in Browser History
• 5.1.6. Access Tokens

在我编写的应用程序中， token 已存储在本地存储和内存中。

我建议您仔细阅读 OAuth 2.0 规范，以便您了解使用 OAuth 2.0 时涉及的风险。