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

这里有几个有用的选项。桌面和移动的浏览器对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服务器的默认最大头大小，这并不理想。