使用 OAuth 2.0 授权代码流识别浏览器（用户代理）会话

Question

在 OAuth 2.0 授权代码流中协调浏览器/用户代理会话与客户端的标准最佳实践方法是什么？

在 OAuth 2.0 授权代码流程中，客户端（您正在使用的 Web 应用程序）直接从授权服务器获取访问令牌。访问令牌永远不会暴露给浏览器/用户代理，这是代码流的重要优势之一。客户端安全性保留访问令牌（和刷新令牌，如果提供），以便它可以将其重用于来自用户的后续请求（通过浏览器/用户代理）。

这就引出了一个问题：客户端和浏览器/用户代理如何传达用户的会话，以便客户端“知道”代表用户使用哪个访问令牌，并且可以这样做？

我找到了客户端为浏览器/用户代理创建会话 cookie 的示例代码。这行得通，但似乎重新打开了基于 cookie 的漏洞利用的大门。有一些标准方法可以防止它们，但我认为 OAuth 2.0 的一个好处是完全避免了这些攻击。 （此外，我们托管了一个 Web REST API，因此没有要发布的表单，我希望保持 API 接口干净、简单并基于标准安全方法。）

注意事项：

• OAuth's tokens and sessions in REST 实际上并没有回答这个特定的问题，尽管我也喜欢 Greg Beech 的回答。

• 问题Understanding OAuth and client sessions 有类似的意图，但答案不适用于我们的案例。

• 这个问题是关于来自用户代理的后续请求，而不是关于回调处理程序。

• 我们完全期望并打算我们的 REST 请求不会是无状态的，并且客户端将维护用户会话的状态信息。出于很好的理由，我宁愿不 枚举这里，我们不是在做一个无状态的 REST 接口。

Answer 1

我会以我认为我理解的方式重新陈述您的问题。 OAuth2 授权代码流的好处是敏感访问令牌不通过用户代理，因此不受用户代理安全漏洞的影响。好吧，如果用户代理的安全漏洞是一个问题，那么客户端为什么要使用 cookie 来维护与用户代理的会话呢？客户端不应该使用替代机制来维护与用户代理的会话吗？

好吧，这是我的答案……

我相信最佳实践仍然是让 Web 应用 OAuth 客户端使用 cookie 来维持与用户代理的会话。 Cookie 具有众所周知的安全属性。但 OAuth 访问令牌的用途与 cookie 不同。

我不认为 OAuth2 旨在缓解基于 cookie 的攻击。 OAuth2 的主要目的是允许用户将对其数据的访问权限委托给客户端，而无需将用户凭据暴露给客户端。此外，使用 OAuth 隐式流，访问令牌在用户代理中以 cookie 没有的方式公开。

基于 Cookie 的漏洞利用肯定会允许攻击者伪装成用户并导致 Web 应用 OAuth 客户端使用其访问令牌访问 OAuth 资源中的用户数据。然而，用户本人是基于 cookie 的攻击的主要攻击媒介（例如：用户访问执行 XSRF/CSRF 的恶意站点）。但这不是 OAuth 授权服务器的工作来防止这种情况发生。 OAuth 授权服务器的工作是根据用户同意确保正确的客户端获得正确的访问令牌。