oauth2.0 处理大小超过4096字节的Cookie-最佳实践

sg24os4d  于 2023-10-15  发布在  其他
关注(0)|答案(2)|浏览(179)

我面临着在Web应用程序中处理Cookie的挑战,在该应用程序中,我存储了Microsofttonline发布的访问令牌和刷新令牌。这些令牌的组合大小有时会超过大多数浏览器规定的4096字节限制。我想确保我遵循管理这种情况的最佳做法。
我的问题是:当cookie的大小超过4096字节时,建议采用什么方法来处理它们?我是否应该将cookie分成两个单独的cookie,一个用于访问令牌,另一个用于刷新令牌?或者,将访问令牌存储在服务器端,并在cookie中仅包含标识符是否更好?
我很欣赏将所有必要信息存储在cookie中以进行无状态操作的便利性,但我担心超过浏览器的cookie大小限制。这两种方法的优点和缺点是什么?在这种情况下,是否有其他管理cookie的最佳实践?

roqulrg3

roqulrg31#

通常,最简单和最安全的方法是将令牌存储在服务器端(在某些DB中)。您可以创建一个会话标识符,并将该标识符用作在数据库中查找令牌的键。您可以获得更好的安全性,因为令牌不能通过浏览器泄漏。只要确保标识符被创建、存储和明智地使用。You can have a look at Session ID sections in OWASP's cheat sheet.
并不是每个人都在使用服务器,你必须小心会话标识符。而且,如果你存储令牌,在访问authz服务器检查令牌是否仍然有效之前,可能需要先向你的服务器/数据库发出额外的请求。
如果可以的话,您可以在访问和刷新(以及ID,如果您正在使用它)之间拆分令牌。你甚至可以用指向下一个片段的指针将它以一定的间隔分开。即使其中一个令牌可能超过该限制,这也会有所帮助。这不是很容易实现,而且有多个片段更容易出错(也有一个~500个总cookie的限制)。需要平衡风险和回报/便利。
另一个可能的选择是避免前端加载数据请求。也就是说,只在需要的时候请求数据,而不是一开始就请求所有数据。这是假设令牌信息与它们的功能无关,并且您不会一次获得所有信息。

gjmwrych

gjmwrych2#

这里有几个有用的选项。桌面和移动的浏览器对Cookie请求标头的限制为4KB。一些HTTP服务器,如NGINX,也有4KB的默认头大小限制。

酒店COOKIE PATHS

你可能会有四个饼干。对于任何特定的请求,使用路径应该确保您保持在4KB的限制之下。下面是一个示例:

  • AT:访问令牌cookie。路径为/API
  • CSRF:用于数据更改命令的防伪令牌,路径也为/API
  • RT:刷新令牌cookie,路径为/refresh
  • ID:ID令牌cookie,路径为/claims

当cookie存储在令牌中时,请使用强对称安全算法对其进行加密。密钥必须是后端专用的,并且偶尔轮换。

不透明代币

在支持的情况下,以不透明格式(类似于UUID)为Internet客户端发出访问和刷新令牌,以便无法读取令牌内容。这是一种隐私最佳实践,也会导致较小的cookie,这些cookie应继续加密。

酒店SENDEND TOKEN STORES

如果可能的话,我宁愿避免这些,因为它们增加了复杂性,并可能成为一个漏洞。在OAuth中,授权服务器应该为您完成这项工作,就像使用不透明令牌的情况一样。因此,我认为这是一个备份选项,如果cookie大小得到进一步减少,而不是一个选项,应该在默认情况下使用。

** JWT 解决方案,以比较**

出于兴趣,我使用了cookies containing tokens模式与JWT和不透明令牌。你可以运行我的Online SPA which uses AWS Cognito JWTs来查看请求。它适用于所有移动的和桌面浏览器。当我在NGINX环境中运行它时,我不得不增加HTTP服务器的默认最大头大小,这并不理想。

相关问题