oAuth 2.0中的弱点-有哪些替代方案？

我正在开发一个使用ASP.NET web api框架构建的api的移动应用程序。我们决定使用ACS和custm STS作为保护api的机制。 我们使用自定义STS，因为我们需要根据自己的标识存储对用户进行身份验证

信息流如下：

移动应用程序使用用户凭据调用自定义STS

用户根据我们自己的身份存储进行身份验证

一旦用户通过身份验证，将从ACS检索授权码，并用于检索SWT访问令牌

令牌返回到移动应用程序

移动应用程序在授权头中嵌入访问令牌，并向API发出请求

API中的HTTP模块验证访问令牌，如果令牌有效，则返回数据

一切都是通过SSL完成的，因为我们使用的是oAuth 2.0

oAUth 2.0的问题在于它面临中间人攻击的风险，因为ACS发布的SWT令牌是原始令牌，并且没有以任何方式进行加密。但是，它是使用256位对称密钥签名的

我们之所以使用swt令牌，是因为我们使用的是基于http的方法，并且令牌非常适合http请求的auth头

Microsoft在以下帖子中提供了一些ACS安全指南：

我们目前在检查发卡机构和受众时实现了其中的2个，即令牌是由我们的可信发卡机构（ACS）发行的，并且令牌是为正确的受众（我们的api）发行的

我们的场景基于以下文章： 因此，WIF不用于处理传入令牌。WIF仅用于索赔处理

鉴于上述场景，我们还可以做些什么来改进实现，以确保基于rest的api的安全

欢迎提出任何意见/批评/建议

---

谢谢。

我想你已经采取了正确的方法。最重要的是验证令牌是否由ACS签名。切勿与其他人共享您的ACS密钥。如果他们不知道密钥，他们就不能伪造签名

---

也不要在令牌中存储机密信息（如密码、信用卡号等）。您应该知道代币可能由其他人获得，但没有人可以伪造具有正确签名的代币。

非常感谢。此外，如果有关于在.NET中用ACS实现oauth 1.0的资料，请提供。有几个与oauth相关的ACS SDK示例。例如：SSL减轻了中间人攻击的风险。如果没有它，你的应用程序肯定会遭到这种攻击。