几乎每个论坛都有很多关于 Web 应用程序安全性（不考虑移动应用程序）的讨论，特别是使用 oauth2 和 jwt。每个人都发表他们的评论/回答这个和那个，blah..blah..blah 关于安全令牌（假设几乎所有有价值的网络都可能在“2016”接近尾声时变得无国籍）。说真的，我不知道这是否那么容易，我发现每个人都在针对想象中的攻击者写下他们的答案，就好像攻击者窃取用户的客户端 Web 应用程序 access_token 和 refresh_token 一样轻松和容易。攻击者实际上可以通过哪些可能的方式破坏您的 Web 应用程序在客户端发出的 access_token 和 refresh_token？这种妥协是否也取决于使用网络应用程序的用户？攻击者窃听客户端和授权服务器之间的任何通信的难易程度如何？如果有人想展示，任何开放代码示例都将受到高度重视。寻求切中要害的答案，而不是厌烦关于 Web 应用安全性的讨论。如果碰巧是Quora之类的问题，我想道歉。
问问题
89 次
1 回答
1
一般来说，有很多关于 OAuth2 安全性的合理问题。
几年前，当 OAuth2 只是一个草案时，该规范的主要贡献者之一就该主题撰写了一篇有趣的博客文章。他是对的：开箱即用，这个框架协议提供了很多可能性来轻松模拟客户端并访问用户资源或发送有效请求，包括管理请求。
主要原因是RFC6749明确指出它依赖于 TLS 连接。除非导出访问令牌，否则攻击很少依赖于用户。中间人、恶意移动应用程序、逆向工程、蛮力……是获取访问令牌的一些可用方法。很难获得所有类型攻击的详尽列表。
然而，由于它是一个框架协议，没有什么能阻止实现额外的安全功能。这就是为什么IETF OAuth2 工作组正在致力于一些非常有趣的增强功能，以保护所有利益相关者（客户端、授权服务器、资源服务器）以及它们之间的通信。
我建议您阅读以下 RFC 或草稿：
- RFC6819：为 OAuth 提供额外的安全注意事项。
- RFC7800 , POP Key Distribution和POP Architecture尝试替换废弃的MAC 访问令牌
- RFC7009用于令牌撤销
- RFC7521、RFC7521和RFC7521实现基于 JWT 或 SAML2 断言的新客户端身份验证方法
- RFC7636 : Proof Key for Code Exchange 防止恶意移动应用获取授权码和访问令牌
此外，您可能还对令牌绑定草案感兴趣，它（来自我的 POV）是一项重大改进，因为它将令牌绑定到 TLS 连接。换句话说，即使访问令牌被泄露（或故意导出），它也不能被使用，因为 TLS 连接会有所不同。
更多与 OAuth2 安全性相关的草案可在IETF OAuth2 工作组页面上找到（请参阅签名请求、关闭重定向器、X.509 客户端身份验证......）。
于 2016-10-13T08:00:31.990 回答