这个问题已经很多了，但是我还没有找到答案。我已经阅读了OAUTH 2规范和单独的安全性“注意事项”文档，但是我对某些内容仍然感到困惑。
这种情况是:移动应用程序正在访问基于REST风格的Web服务。我既是服务器资源(RESTful服务的创建者和主机)，又是授权机构(我存储用户的ID和密码并验证身份)。第三方公司创建使用我的服务的移动应用程序。我正在使用OAuth 2.0验证用户的UserID和密码并颁发 token 。使用通过https进行的TLS。
带有单个消息的随机数通常用于防止重播攻击，但是据我所知，在移动应用程序中它不起作用，因为要对消息进行签名，您需要一个共享的 secret 。移动应用程序上存储的所有 secret 信息(允许您对消息进行签名)已不再是 secret 信息。因此，不能使用随机数。
因此，我们有 session token ，这些 session token 会在一段可配置的时间段后过期，并且可以使用“刷新 token ”进行刷新。
我的问题是:如果TLS被打败(例如:用户愚蠢到足以将手机连接到代理服务器并安装代理证书，然后允许代理服务器所有者读取未加密的流量)，是什么导致了黑客是否使用有效的 session token (虽然它仍处于事件状态)重播请求，或更糟的是使用刷新 token 一次连续保持 session 数小时，以不断获取新的 session token ？
最佳答案
您建议的情况是安全性遭到破坏而没有安全性的情况。代理可以执行诸如在身份验证期间窃取用户密码或将访问 token 转移到另一个应用程序(本地或远程)的操作。您必须只接受这种情况作为损失。
同样，移动应用程序通常具有共享的 secret 。正如您所指出的那样， secret 会失去客户端上的某些安全性，但总比没有好。 secret 通常会在静止时进行加密，以防止其轻易被盗。当然，即使对加密技术应用了解密 key ，也可以从应用程序中窃取解密 key ，但是它提供了一定的安全性。
确保限制客户端上 secret 的访问权限。确保未为两足式身份验证配置它。应该将其保存在服务器上，并且仅在需要时保存。
关于mobile - Oauth 2如何防止移动应用程序中的重播攻击？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22198211/