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

Question

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

信息流程如下：

1. 移动应用使用用户凭据调用自定义STS。
2. 用户通过我们自己的身份存储区进行身份验证。
3. 用户通过身份验证后，将从ACS检索授权代码并用于检索SWT访问令牌。
4. 令牌返回移动应用程序。
5. 移动应用程序在授权标头中嵌入访问令牌并向API
触发请求
6. API中的HTTP模块验证访问令牌，如果令牌有效，则返回数据。

当我们使用oAuth 2.0时，一切都通过SSL完成。

oAUth 2.0的问题在于它受到中间人攻击的威胁，因为ACS发出的SWT令牌是一个原始令牌而且没有以任何方式加密。但是，它使用256位对称密钥进行签名。

我们正在使用swt令牌，因为我们使用的是基于http的方法，并且令牌非常适合http请求的auth标头。

Microsoft已在以下帖子中提供了一些ACS安全准则： http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx

当我们检查发行人和受众时，我们目前正在实施其中的两个，即令牌是由我们的受信任发行人（ACS）发出的，并且令牌是为正确的受众（我们的api）发出的。

我们的方案基于以下文章： http://msdn.microsoft.com/en-us/library/hh446531.aspx 因此，WIF不用于处理传入的令牌。 WIF仅用于索赔处理。

鉴于上述情况，我们还有什么方法可以改进实施，以确保我们基于休息的api？

任何和所有评论/批评/建议都欢迎。

谢谢。

Answer 1

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

也不要在机密信息中存储机密信息（如密码，信用卡号等）。您应该期望其他人可以获得令牌，但没有人可以使用正确的签名伪造令牌。