4

我正在开发一个使用 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

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

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

鉴于上述情况，我们还可以做些什么来改进我们必须保护基于休息的 API 的实现？

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

谢谢你。

4

1 回答 1

2

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

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

于 2012-06-11T05:26:26.753 回答