18

我有一个使用 WebAPI 构建的 Web 服务，它接受 JSON 请求并做出相应的响应。核心架构已构建，但没有任何身份验证/授权。

经过大量谷歌搜索和浏览示例项目后，我不知道从哪里开始。我发现了 2008 年和 2009 年的大量材料，但没有找到很多 WebAPI/单页应用程序的最新指南/工作流程。我认为工作流程应该如下：

  1. 检查用户是否已登录：如何使用 javascript 完成此操作？我是否将 cookie 发送到我的 webAPI？如果是这样，我是否将该 cookie 作为请求正文中的参数发送？

  2. 让用户登录/注册：这些数据是如何加密/解密的？当然，我不能通过网络发送密码……这就是 SSL 的用武之地吗？

  3. 为他们提供对他们有权访问的内容的访问权限：我想我明白了 - 我可以根据每个请求在控制器中授权。

任何信息都会很棒。

4

2 回答 2

8

基本上，您需要基于令牌的身份验证或授权。如果您指的是 ASP.NET WebAPI，以下项目将是一个很好的起点： http ://thinktecture.github.com/Thinktecture.IdentityModel.45/

即使您不使用 ASP.NET WebAPI，以下视频也很好地介绍了如何在 RESTful Web 服务上提供身份验证/授权：http: //vimeo.com/43603474

要回答您的一些问题：

检查用户是否已登录：如何使用 javascript 完成此操作？我是否将 cookie 发送到我的 webAPI？如果是这样，我是否将该 cookie 作为请求正文中的参数发送？

您可以使用 cookie，但我通常使用标头来避免常见的 XSRF 攻击。每当从浏览器发送 http 请求时，都会自动包含 Cookie。

这是 SSL 的用武之地吗？

是的。如果您打算继续使用基于令牌的方法，您可以使用单独的服务器（身份服务器）为您进行身份验证。

于 2013-04-04T01:45:53.277 回答
3

JavaScript 客户端是独一无二的。您是否在同一个域中拥有 Web API 和提供 JavaScript 的页面？如果不是，则您有相同的来源政策限制。如果您拥有托管网页和 Web API 的相同 Web 应用程序，则可以使用表单 Authn。在这种情况下，您不需要自己从 JavaScript 发送包含身份验证票的 cookie。浏览器会为你做这件事，这就是 XSRF 问题的原因。您必须小心 JavaScript 发送最终用户不应该知道的凭据。如果 JavaScript 知道一些东西，任何聪明的最终用户都可以得到这些知识。OAuth 2.0 隐式授权可能是一个不错的选择。最终用户在颁发访问令牌的授权服务器中输入凭据（密码）。

于 2013-04-09T02:45:12.857 回答