我正在使用一个使用 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 安全准则：http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
我们目前在检查发行者和受众时实现了其中的 2 个，即令牌是由我们的受信任发行者（ACS）发行的，并且令牌是为正确的受众（我们的 api）发行的。
我们的场景基于以下文章：http://msdn.microsoft.com/en-us/library/hh446531.aspx，因为这样的 WIF 不用于处理传入令牌。WIF 仅用于声明处理。
鉴于上述情况，我们还可以做些什么来改进我们必须确保基于 REST 的 api 的实现？
任何和所有的意见 / 批评 / 建议欢迎。
非常感谢。
我认为你已经采取了正确的方法。最重要的是验证令牌是否由 ACS 签名。永远不要与其他任何人共享您的 ACS 秘密密钥。如果他们不知道密钥,则无法伪造签名。
也不要在令牌中存储机密信息（例如密码，信用卡号等）。您应该期望令牌可能被其他人获得，但是没有人可以伪造具有正确签名的令牌。
本站系公益性非盈利分享网址，本文来自用户投稿，不代表边看边学立场，如若转载，请注明出处
评论列表（6条）