几乎每个论坛都有很多关于使用oauth2和jwt的Web应用程序安全性（不考虑移动应用程序）的讨论。每个人都提出他们的意见/答案，以及关于安全令牌的blah..blah..blah（假设几乎所有有价值的网络都可能在2016年的近期结束时无国界）。说真的，我不知道它是否如此简单，我发现每个人都对一个想象中的攻击者写下他们的答案，好像它是如此放松，很容易让攻击者窃取用户的客户端web应用程序access_token和refresh_token。攻击者可以通过多种方式破坏您在客户端发布的access_token和refresh_token的Web应用程序？这种妥协是否也取决于用户使用网络应用程序？攻击者可以轻易窃听客户端和授权服务器之间的任何通信？任何想要展示的任何开放代码示例都将受到高度重视。寻求答案，而不是讨论有关Web应用程序安全性的讨论。如果碰巧像Quora那样的话，我想道歉。
答案 0 :(得分：1)
一般来说，关于OAuth2安全性有很多合理的问题。
几年前，当OAuth2只是一个草案时，该规范的主要贡献者之一就该主题写了an interesting blog post。 他是对的：开箱即用，这个框架协议提供了很多可能性，可以轻松冒充客户端并访问用户资源或发送有效请求，包括管理员请求。
主要原因是RFC6749清楚地表明它依赖于TLS连接。除非导出访问令牌，否则攻击很少依赖于用户。中间人，恶意移动应用程序，逆向工程，暴力......是获取访问令牌的一些可用方法。很难得到所有类型攻击的详尽清单。
但是，由于它是一种框架协议，因此无法阻止实现其他安全功能。 这就是为什么the IETF OAuth2 Working Group正在开展一些非常有趣的增强工作来保护所有利益相关者（客户端，授权服务器，资源服务器）以及它们之间的通信。
我建议您阅读以下RFC或草稿：
此外，您可能也对token binding draft感兴趣，这是（来自我的POV）一项重大改进，因为它将令牌绑定到TLS连接。换句话说，即使访问令牌被泄露（或故意导出），它也不能用作TLS连接会有所不同。
有关OAuth2安全性的更多草稿可在the IETF OAuth2 Working Group页面上找到（请参阅signed requests，closing redirectors，X.509 Client authentication ...）。