在 cookie 中存储 OAuth 令牌是不好的做法吗？

Question

在 cookie 中存储 OAuth 2 令牌是不好的做法吗？如果是这样，网络应用程序的替代品是什么？

Answer 1

是否可以将access_token存储在cookie中取决于以下几点：

cookie中存储的access_token是否加密（肯定应该加密）
Access_token 是一个不记名令牌，因此它与浏览器流无关。 Cookie 通常用于维护浏览器中的状态。因此，如果 token 的生命周期与 cookie 相同，则继续，否则不。当我说生命周期时，我指的是寿命等。
此外，还请考虑访问令牌不是身份令牌这一事实
访问令牌完全是客户端的，通常使用 cookie 来维护会话的服务器也大多维护匹配的服务器端会话。

我希望这有帮助。

Answer 2

我绝对不会这么做。当涉及到安全时，您不应该将东西存储在其他人可以访问的地方。所以不要将其存储在任何地方，尤其是客户端。

话虽如此，如果处理得当，这本身并不是一个坏习惯。请参阅this有关它的综合文章。

Answer 3

Cookie 的最大大小为 4kb。因此，如果您在令牌中保存大量信息 - 您将会收到错误。

Answer 4

如果操作正确，在 cookie 中存储访问令牌可以为您提供最好、最可靠的浏览器安全性。

最强的浏览器存储

Cookie 使用仅 HTTP 和 SameSite=严格设置。它们始终使用强大的算法（例如 AES256-GCM）进行加密。

访问令牌饼干

以参考格式颁发访问令牌，类似于 UUID。将其加密为安全 cookie，该 cookie 的大小将很小并且永远不会超出浏览器限制。

将刷新 / ID cookie 发布到单独的路径，例如

/refresh

和

/id

，以便这些 cookie 不会在 API 请求中发送。限制 cookie 发送是一个很好的做法。

访问令牌 cookie 是一种 API 凭证，只能发送到 API 的 Web 入口点。这些受 OWASP CSRF 预防最佳实践保护。

利用窗口

访问令牌 cookie 只是一个 HTTP 标头。如果以某种方式被盗，它的生命周期与访问令牌相同，例如 15 分钟。与某些会话 cookie 解决方案相比，这减少了利用时间，这些解决方案可能提供可重播数小时的标头。

并发 API 请求

一些会话 cookie 解决方案源自网站设计，用于在每次用户操作时重新加载整个页面。而现代 JavaScript 应用程序通常会布局视图树，这可能会同时调用 API：

<>
  <View1 />
  <View2 />
  <View3 />
</>

对于此类应用程序，无论您使用什么 cookie 解决方案，请确保它能够可靠地处理并发请求和过期条件。

如果使用访问令牌 cookie，当访问令牌过期时，所有 3 个视图都将收到 401 响应。然后，应用程序需要执行同步令牌刷新，以重写访问令牌 cookie，然后重试所有 3 个 API 调用，如我的这段代码。

如果访问令牌更新发生在服务器端，则可能更难确保可靠性，从而导致竞争条件，其中某些视图请求导致令牌刷新由于使用旧的刷新令牌而失败。

总结

使用最新的 cookie 是 OAuth 最佳实践。目标是缩短 API 凭证的生命周期，这是 OAuth 的核心原则。但也要根据您正在构建的应用程序的风格选择可靠的设计。

Answer 5

是的，只有安全地存储它才可以。请点击此链接了解有关 cookie 安全性的更多信息。 https://techblog.topdesk.com/security/cookie-security/