背景：我目前正在负责为伦敦大学学院建立API的团队。
我负责构建OAuth的实现，它位于我们可以提供给用户的Shibboleth之上。为了使其尽可能安全（我们将提供学生数据，因此我们不能冒任何风险），我已经实现了一个nonce参数以及client_secret_proof参数（{{1在sakurity.com/oauth上描述。
不同之处在于，在我的实现中，对nonce端点发出请求，然后将此nonce值连接到用户的令牌上，然后运行HMAC算法，以便无法重播appsecret_proof参数。
这里的问题是我的PM认为这种额外的保护是不必要的，对开发者体验来说太糟糕了，但是我想尝试尽可能地使MITM连接变得困难并尽可能地防止泄漏我们的学生开发人员通过草率编程的客户机密。我是在浪费时间在这里强化OAuth，还是在防止某些类型的攻击时OAuth 2.0本身就很弱？我主要担心的是开发人员没有正确验证HTTPS证书，这会导致HTTPS中已存在的保护措施。
非常感谢你对此有任何想法！我们不想提供糟糕的开发者体验，但我们也不想让任何攻击媒介都不予考虑。
实施保护：https://github.com/uclapi/uclapi/blob/OAuth/backend/uclapi/oauth/decorators.py#L86
客户端库：https://github.com/uclapi/django-uclapi-oauth/blob/master/apidemo/uclapi/views.py
答案 0 :(得分：1)
虽然您没有提到您使用的是哪种类型的OAuth 2.0客户端？ （SPA，Web App或??）。除了OAuth 2.0或OpenID Connect，我不会给我们任何东西。 （因为OpenID Connect使用可以签名和加密的JWT。）
Developer Quits OAuth 2.0 Spec, Calls It ‘a Bad Protocol'是在2012年，从那以后事情已经不用说了。
大多数弱点都是由A Comprehensive Formal Security Analysis of OAuth 2.0（2016年完成）指出的实施弱点造成的
即使从2016年开始，从Security Considerations角度来看，OAuth 2.0和OpenID连接也有一些增强功能。
在今天的网络环境中，什么是“太安全”＃34;在处理敏感信息时，如果违规行为可能会损害组织的声誉？