RESTful Web服务中的身份验证

Question

我目前正在创建一个用户可以查看和修改其小部件的网站.所有与存储在我的服务器上的小部件数据的交互都将通过RESTful Web服务完成.例如,如果用户想要查看其小部件列表,则执行流程将类似于:

1. 用户12345访问https://www.example.com/Login.htm服务器并进行身份验证(在我的情况下通过OpenID提供程序)
2. 然后,用户12345访问该页面 https://www.example.com/Widgets.htm
3. 服务器响应HTML页面和javascript,用于访问我的Web服务.
4. 当HTML页面加载时,getWidgets()将调用javascript函数.getWidgets()将致电我的网络服务https://www.example.com/Services/Widget/12345
5. 该服务响应用户窗口小部件的列表,另一个javascript函数renderWidgets(widgets)将更新html页面

我不希望除了用户12345以外的任何人访问他们自己的小部件,所以我想我getWidgets()必须为我的网络服务提供一些身份验证.我不确定实现这一目标的最佳方法是什么.

我当时认为客户端和服务器可能有共享密钥getWidgets()将发送到Web服务.服务器可以生成此秘密作为随机字符串(数字,GUID或其他),并在客户端请求初始HTML页面时将其包含在响应头中.客户端在向服务器发送请求时将使用此密钥.

这听起来像是一个明智的想法吗？

这是一个常见的要求,那么是否有一种实现同样目标的标准方法？据我所知,这超出了OpenID的范围,OAuth也不合适.

提前致谢.

Answer 1

这是一个很好的问题 - 但我认为您的解决方案可能需要比您想象的更复杂一些.

通常,您希望对此类方案进行身份验证的方式是两阶段握手.第一步是为您的应用程序提供服务器私钥(由服务器生成,对客户端应用程序是唯一的),以验证它实际上是一个有效的客户端.这为您的服务器提供权威证据,证明该请求来自它知道且可信任的软件.

第二步是,当用户登录到您的客户端应用程序时,他们提供用户名/密码组合.这些信息以及您的应用程序密钥都应通过SSL发送到服务器.

SSL会对数据进行加密,以便具有数据包嗅探器的第三方无法读取传输中的数据,并且服务器会执行以下操作:

1. 检查应用程序密钥是否有效.
2. 验证用户名是否存在,并与应用程序关联.
3. 加密密码并根据与用户名关联的数据库中的加密版本测试加密版本.
4. 如果上面列出的所有检查都通过,则服务器返回会话ID,该会话ID可以放入客户端cookie中,并用于在每个后续请求中重新验证用户身份.如果任何测试失败 - 服务器返回401: Unauthorized响应或其他类似错误.

此时,客户端可以利用返回的会话ID,而无需继续重新提交应用程序密钥.

你的申请

现在,在您的情况下,您可能实际上在同一个应用程序和同一服务器上托管客户端/服务器.在这种情况下 - 您通常可以跳过围绕私有应用程序密钥的所有部分 - 而只是禁止跨站点脚本请求.

为什么？ - 因为您真正要防范的是以下内容:

服务器A托管您的RESTful API.客户端的B,C和D主机客户端将依赖于服务器A的API.您不希望客户E(不是您的应用程序 - 和恶意)通过绕过或窃取其他客户端的凭据来访问服务器A.

但是,如果客户端和服务器都托管在同一个地方,因此具有相同的URL - 即RESTful API驻留在www.yourdomain.com/api客户端所在的位置www.yourdomain.com/- 您通常只是不允许任何源自yourdomain.com- 和 - 之外的任何AJAX类型请求这是你的安全层.

在这种情况下,您需要执行以下操作才能获得合理的安全级别:

1. 为您的服务器启用SSL.
2. 只允许通过SSL发出请求/auth/login(或任何您的登录POST方法)(在C#中,这可以通过使用[RequireHttps]方法或控制器上的属性来完成).
3. 拒绝任何源自您自己域之外的AJAX请求.
4. 在Cookie中使用一层加密.

你的cookie应该包含什么？

理想情况下,cookie应包含双向加密数据,只有您的服务器才能解密.换句话说 - 您可以放置​​类似用户username或user_idcookie内部的东西- 但是使用Rijndael或其他加密系统对其进行双向加密 - 使用只有您的服务器可以访问的加密密码(我建议使用随机字符串).

然后 - 当您收到随附cookie的后续请求时,您可以简单地执行以下操作:

1. 如果cookie存在,请尝试使用您的私人密码对其进行解密.
2. 如果生成的解密数据是垃圾 - 抛出401: Unauthorized响应(这是一个更改或伪造的cookie)
3. 如果生成的解密数据是与您的数据库匹配的用户名 - 您现在知道谁在提出请求 - 并且可以相应地过滤/提供数据.

我希望这有帮助.:)如果没有 - 随意发表任何评论并提出问题,我会尽力澄清.