OAuth 和 OpenId Connect 令牌说明

Posted 2023-03-10

【中文标题】OAuth 和 OpenId Connect 令牌说明

【英文标题】：OAuth and OpenId Connect Tokens clarification

【发布时间】：2021-08-02 13:14:38

【问题描述】：

我对 OAuth 和 OpenId Connect 做了一些扎实的研究（恕我直言）。但我仍然不完全确定保护每个令牌的内容和方法。让我们暂时搁置刷新令牌，让我们专注于 ID 令牌和访问令牌。从安全的角度来看，两者必须一视同仁。它们不能泄露公共，因此只能与 HTTPS 一起使用，并避免在客户端以不受保护的读取/使用进行存储。由此，我假设我只能使用 httpOnly cookie（XSS、CRFS 保护、库泄漏）来存储简单网站的令牌（服务器端是 JWT 的发行者）。是否可以将访问令牌（直接或作为声明包装在 ID 令牌中）存储在 cookie 中（我不考虑令牌与会话 id 的大小），或者我应该将其存储为服务器端，因此使用经典会话解决方案一个简单网站的案例？ 在 SPA API ( API...) 的情况下，我应该/必须使用 Bearer 令牌解决方案吗？

我认为我理解正确，但想确定一下。

谢谢

【参考方案1】：

理想情况下，您应该将令牌存储在后端，并可能在客户端和后端之间使用简单的会话 cookie。

默认情况下，某些服务（如 ASP.NET Core）会将令牌存储为 cookie。为了保护 cookie，他们会在将其发送到浏览器之前对其进行加密。所以这意味着即使 cookie 被盗，也无法解密，因此令牌是安全的。

是的，cookie 大小会非常大，但 ASP.NET Core 通过将大 cookie 分成 4 Kb 的块来解决这个问题。如果您使用带有标头压缩的 HTTP/2，大型 cookie 不会影响传输时间。

【参考方案2】：

如果您打算直接从前端应用程序使用访问令牌，通过对 API 进行一些 AJAX 调用，那么您不能将访问令牌保存在 httpOnly cookie 中。您的脚本将需要访问它。如果您是单页应用程序，您可以将令牌保存在内存中。只要用户不刷新页面，令牌就可以使用。刷新后，您可以执行静默登录以从后端获取新令牌。

如果您有一个简单的网站，并且不直接从前端执行任何对 API 的调用，我会坚持使用普通的旧会话。在这种情况下，您不会从会话中使用访问令牌获得任何额外价值。

在 SPA API ( API...) 的情况下，我应该/必须使用 Bearer 令牌解决方案吗？

不知道你在这里问什么。如果您的意思是在 SPA 和 API 之间进行通信时，您必须在 Authorization 标头中使用访问令牌而不是发送 cookie，那么是的，您是对的。如果您要问是否一定要使用不记名令牌，那么没有 - 有一种称为发送方约束令牌的东西，这意味着访问令牌与发出它的客户端相关联。