在OAuth 2.0授权代码流中协调浏览器/用户代理会话与客户端的标准最佳实践方法是什么？
在OAuth 2.0授权代码流中，客户端（您正在使用的Web应用程序）直接从授权服务器获取访问令牌。访问令牌永远不会暴露给浏览器/用户代理，这是代码流的重要优势之一。客户端安全性保留访问令牌（以及刷新令牌，如果提供），以便它可以将其重用于用户的后续请求（通过浏览器/用户代理）。
这导致了一个问题：客户端和浏览器/用户代理如何传达用户的会话，以便客户端“知道”代表用户使用哪个访问令牌，并且可以这样做？
我找到了客户端为浏览器/用户代理创建会话cookie的示例代码。这很有效，但似乎重新开启了基于cookie的漏洞。有一些标准方法可以防止它们，但我认为OAuth 2.0的一个好处是完全避免这些攻击。 （此外，我们正在托管Web REST API，因此没有POST表单，我希望保持API接口干净，简单，并基于标准安全方法。）
注意：
OAuth's tokens and sessions in REST 实际上并没有回答这个问题，尽管我也喜欢Greg Beech的回应。
问题Understanding OAuth and client sessions 有类似的意图，但答案不适用于我们的案例。
这个问题是关于来自用户代理的后续请求，而不是关于回调处理程序的请求。
我们完全期望并打算我们的REST请求不会是无状态的，并且客户端将维护用户会话的状态信息。出于很好的理由，我宁愿不这样做 在这里列举，我们没有制作无状态REST接口。
答案 0 :(得分：1)
我会以我认为理解的方式重新陈述你的问题。 OAuth2授权代码流的好处是敏感访问令牌不通过用户代理传递，因此不会受到用户代理的安全漏洞的影响。那么，如果用户代理的安全漏洞是一个问题，那么为什么客户端应该使用cookie来维护与用户代理的会话？客户端是否应该使用备用机制来维护与用户代理的会话？
嗯，这是我的答案......
我认为最佳做法仍然是网络应用OAuth客户端的Cookie，以维护与用户代理的会话。 Cookie具有众所周知的安全属性。但OAuth访问令牌与Cookie的用途不同。
我认为OAuth2不是为了缓解基于cookie的攻击。 OAuth2的主要目的是允许用户将对其数据的访问权委托给客户端，而不会将用户凭据暴露给客户端。此外，使用OAuth Implicit Flow，访问令牌在用户代理中以不包含cookie的方式公开。
基于Cookie的攻击当然可以允许攻击者伪装成用户并使Web应用程序OAuth客户端使用其访问令牌来访问OAuth资源上的用户数据。但是，用户自己是基于cookie的漏洞中的主要攻击媒介（例如：用户访问执行XSRF / CSRF的恶意站点）。但是OAuth授权服务器的工作不是要防范它。根据用户的同意，OAuth授权服务器的工作是确保正确的客户端获得正确的访问令牌。