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

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

在OAuth 2.0授权代码流中，客户端（您正在使用的Web应用程序）直接从授权服务器获取访问令牌。访问令牌从不向浏览器/用户代理公开，这是代码流的一个重要优点。客户端安全性保留访问令牌（以及刷新令牌，如果提供的话），以便可以将其重新用于用户（通过浏览器/用户代理）的后续请求

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

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

注:

• 虽然我也喜欢格雷格·比奇的回答，但实际上并没有回答这个问题

• 问题 有类似的意图，但答案不适用于我们的情况

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

• 我们完全期望并打算我们的REST请求不会是无状态的，客户端将维护用户会话的状态信息。有很好的理由我不想 在这里枚举，我们不是在创建无状态REST接口

---

我将以我认为我理解的方式重新陈述您的问题。OAuth2授权代码流的好处是敏感访问令牌不会通过用户代理传递，因此不会受到用户代理上的安全漏洞的影响。那么，如果用户代理的安全漏洞是一个问题，那么客户端为什么要使用cookie来维护与用户代理的会话呢？客户端不应该使用替代机制来维护与用户代理的会话吗
好吧，这是我的答案
我相信最好的实践仍然是web应用OAuth客户端使用cookies来维护与用户代理的会话。Cookie具有众所周知的安全属性。但是OAuth访问令牌的用途与cookie不同
我不认为OAuth2是为了减轻基于cookie的攻击。OAuth2的主要目的是允许用户将对其数据的访问委托给客户端，而不向客户端公开用户凭据。此外，使用OAuth隐式流，访问令牌在用户代理中的公开方式与cookie不同

---

基于Cookie的漏洞利用肯定会允许攻击者伪装成用户，并导致web app OAuth客户端使用其访问令牌访问OAuth资源中的用户数据。然而，用户自己是Cookie基于漏洞的主要攻击向量（EX:用户访问执行XSRF／CSRF的恶意站点）。但是，OAuth授权服务器的工作不是防止这种情况发生。OAuth授权服务器的工作是确保正确的客户端根据用户的同意获得正确的访问令牌。
感谢您的合理和周到的回复。是的，你理解这个问题，我认为你已经很好地涵盖了这个主题。