攻击者可以破坏 access_token 和/或 refresh_token 的各种可能方式是什么？

Question

几乎每个论坛都有很多关于 Web 应用程序安全性（不考虑移动应用程序）的讨论，特别是使用 oauth2 和 jwt。每个人都把他们的 cmets/answers 这个和那个，blah..blah..blah 关于安全令牌（假设几乎所有有价值的网络都可能在“2016 年”接近尾声时变得无国籍）。说真的，我不知道这是否那么容易，我发现每个人都在针对想象中的攻击者写下他们的答案，就好像攻击者窃取用户的客户端 Web 应用程序 access_token 和 refresh_token 一样轻松和容易。攻击者实际上可以通过哪些可能的方式破坏您的 Web 应用程序在客户端发出的 access_token 和 refresh_token？这种妥协是否也取决于使用网络应用程序的用户？攻击者窃听客户端和授权服务器之间的任何通信的难易程度如何？如果有人想展示，任何开放代码示例都将受到高度重视。寻求切中要害的答案，而不是对 Web 应用程序安全性进行乏味的讨论。如果碰巧是Quora之类的问题，我想道歉。

Answer 1

一般来说，关于 OAuth2 安全性有很多合理的问题。

几年前，当 OAuth2 还只是一个草案时，该规范的主要贡献者之一就该主题写了an interesting blog post。 他是对的：开箱即用，这个框架协议提供了很多可能性来轻松模拟客户端并访问用户资源或发送有效请求，包括管理员请求。

主要原因是RFC6749 明确表明它依赖于 TLS 连接。除非导出访问令牌，否则攻击很少依赖于用户。中间人、恶意移动应用程序、逆向工程、蛮力……是获取访问令牌的一些可用方法。很难获得所有攻击类型的详尽列表。

但是，由于它是一个框架协议，因此没有什么可以阻止实现额外的安全功能。 这就是为什么the IETF OAuth2 Working Group 正在开发一些非常有趣的增强功能，以保护所有利益相关者（客户端、授权服务器、资源服务器）以及它们之间的通信。

我建议您阅读以下 RFC 或草案：

• RFC6819：为 OAuth 提供额外的安全注意事项。
• RFC7800、POP Key Distribution 和 POP Architecture 尝试替换 abandonned MAC access tokens
• RFC7009 用于令牌撤销
• RFC7521、RFC7521 和 RFC7521，它们实现了基于 JWT 或 SAML2 断言的新客户端身份验证方法
• RFC7636：Proof Key for Code Exchange 防止恶意移动应用获取授权码和访问令牌

此外，您可能还对token binding draft 感兴趣，它（来自我的 POV）是一项重大改进，因为它将令牌绑定到 TLS 连接。换句话说，即使访问令牌被泄露（或故意导出），它也不能被使用，因为 TLS 连接会有所不同。

更多与 OAuth2 安全性相关的草稿可在 the IETF OAuth2 Working Group 页面上找到（请参阅 signed requests、closing redirectors、X.509 Client authentication...）。