我对OAuth和OpenId Connect做了一些扎实的研究(IMHO(。但我仍然不完全确定如何保护每一个代币。让我们暂时把刷新令牌放在一边，让我们关注ID令牌和Access令牌。从安全角度来看，两者必须一视同仁。它们不能泄露公共信息，因此只能与HTTPS一起使用，并避免在客户端进行未受保护的读取/使用存储。由此，我假设在简单网站的情况下，我只能使用httpOnly cookie(XSS、CRFS保护、库泄漏(来存储令牌(服务器端是JWT的颁发者(。可以将访问令牌(直接或包装在ID令牌中作为声明(存储在cookie中吗(我不考虑令牌与会话ID的大小(，或者我应该将其存储为服务器端，因此在简单网站的情况下使用经典会话解决方案？在SPA<->；API(<->API…(我应该/必须使用Bearer代币解决方案？
我想我理解得对，但我想确定一下。
感谢
如果您要直接从前端应用程序使用访问令牌，通过对API进行一些AJAX调用，那么您无法将访问令牌保存在httpOnly cookie中。你的脚本需要访问它。如果你是一个单页应用程序，你可以将令牌保存在内存中。只要用户不刷新页面，令牌就可以使用。刷新后，您可以执行静默登录以从后端获取新令牌。
如果你有一个简单的网站，并且不直接从前端执行任何对API的调用，我会坚持使用简单的旧会话。在这种情况下，通过会话使用访问令牌不会获得任何附加值。
在SPA<->；API(<->API…(我应该/必须使用Bearer代币解决方案？
不确定你在这里问什么。如果你的意思是，在SPA和API之间进行通信的情况下，你必须在授权头中使用访问令牌，而不是发送cookie，那么是的，你是对的。如果你问你是否绑定使用承载令牌，那么没有-有一种叫做发送方约束令牌的东西，这意味着访问令牌与它被发送到的客户端绑定。
理想情况下，您应该将令牌存储在后端，并可能在客户端和后端之间使用简单的会话cookie。
某些服务(如ASP.NET Core(默认情况下会将令牌存储为cookie。为了保护cookie，他们会在将其发送到浏览器之前对其进行加密。因此，这意味着即使cookie被盗，也无法解密，因此令牌是安全的。
是的，饼干的大小会很大，但是ASP。NET Core通过将大型cookie分解为4Kb的块来解决这个问题。如果您使用HTTP/2及其标头压缩，则大型cookie不会影响传输时间。