37

问题：

仅使用本地身份验证策略为客户端应用程序提供安全 API。
红色箭头是知识差距的一部分。

在此处输入图像描述

语境：

那就是 ---client.example.com正在发布一个POST到api.example.com/login成功client.example.com可以访问GET服务的地方，例如api.example.com/secret.

一个主意！

使用位于 API 前面的混合授权类型实现 OAuth 2.0。

为什么是混合动力车？

  • 它不会是Implicit Grant Flowaka Client-Side Web Applications Flow，因为没有重定向到 API 服务器也不会授予访问令牌。（即）“某某可以访问您的数据吗？”

  • 这不会是Resource Owner Password Flow因为客户端 ID 和客户端密码与请求一起传递，因此假定客户端应用程序是服务器端的。

好的......那么两者都有一点呢？

如果我们在客户端应用程序的页面加载中使用 CRSF 令牌，并将其与用户凭据一起发布 OAuth 2.0 身份验证端点以交换访问令牌怎么办？成功登录后，您将使用访问令牌和 CRSF 令牌对每个后续请求进行身份验证。

我发现了一个很好的 Node.js OAuth 2.0 库：

https://github.com/ammmir/node-oauth2-provider

帮我！

我找不到解决此问题的身份验证措施的工作示例！指出我正确的方向？

最终，这里的目标是使用 CORS 和本地策略（即用户名和密码）向 REST api 验证客户端应用程序，即使上述约定是不可能的。

容纳赏金：

这是一个客户端应用程序，所以让我们保持时尚。

我正在寻找一个工作示例，使用上面的Node.js OAuth 2.0 种子作为 API/Auth 服务器和前端框架（如Angular.js或Backbone.js）发出请求。

该示例应与上述上下文相匹配。

4

5 回答 5

3

我正在开发一个架构非常相似的应用程序，尽管这些服务是 .NET Web API 而不是 Node，并且我们使用DotNetOpenAuth作为 OAuth 提供程序。而不是您建议的混合方法，我们正在执行以下操作：

  1. x.com 提供登录页面
  2. 登录页面将凭据回传到 x.com
  3. x.com 的服务器端逻辑将 client_id 和 client_secret 与凭据结合以提交令牌请求（您上面提到的资源所有者密码凭据授予）接收临时访问令牌和刷新令牌
  4. 刷新令牌被加密为 x.com 发布的 cookie
  5. 然后将 cookie（带有加密的刷新令牌）和临时访问令牌都发送到浏览器
  6. 客户端应用程序（在我的例子中是 angular）现在可以使用访问令牌来访问 api.x.com 以获取服务（看来您很清楚 CORS 的局限性......我们破解了 angular 的$resource版本以方便但这并不漂亮，因为我们想使用所有 HTTP 动词并支持 IE9）
  7. 当访问令牌过期时，客户端应用程序可以从 x.com 请求新的访问令牌
  8. 在服务器端，x.com 解密 cookie 以获取刷新令牌并发出另一个 oauth 调用以获取新的访问令牌

这是相当高级的，但希望能让您了解如何处理您的情况。就我而言，它出现在您的案例中，我们不想使用会话状态或数据库来存储刷新令牌，但显然将其暴露给浏览器会引入安全问题，因此刷新令牌的加密很重要（以及其他安全性注意事项）并且使用 cookie 消除了对会话状态或 x.com 上其他持久存储的需要。

于 2013-05-01T06:22:29.093 回答
2

我使用 Node 和 PassportJS 构建了这个示例，以展示如何使用 Facebook 或 Local Strategy 对用户进行身份验证。正如您所描述的，双方都在不同的域上，并且需要启用 CORS。

GitHub：https
://github.com/pablodenadai/Corsnection 现场演示：http ://corsnection-client.herokuapp.com/

于 2013-07-19T11:24:53.363 回答
1

不是为了奖品而跑的答案。只是我的 2 美分 :)

在我的网络服务器上，

我通过使用登录/密码的休息调用进行身份验证，并通过 https 进行基本身份验证。此调用将密钥传递给客户端（单页 Web 应用程序）。

然后每个后续的 REST 调用都使用密钥进行签名。服务器检查签名是否正确，并且一切仍然在 https 中发生。

我相信这种机制非常有用。

我没有看到跨域的问题。我有一个单一的来源，如果我需要其他来源的东西，我会使用 JSONP。

我使用 nginx 作为 https->http 转发器。

不确定它如何与 OAuth2 解决方案竞争。

于 2013-04-24T07:04:46.090 回答
0

我不能保证我有时间编写工作示例，但我可以向您展示 2 条路径 :)

最大的一笔交易是 CORS。解决了这个问题之后，就很容易使用$http服务了。因此，首先并且可能最简单的可能是在指向 api.x.com 的 x.com 网络服务器中配置反向代理。我在这里写文章

第二种方法更好，并且正是为此目的而创建的，以授权特定域使用您的资源。它涉及 api.x.com 中的一些编码，因此您无需更改在其他域中提供的新 Web 应用程序中的任何内容。您只需要在 api.x.com 服务中授权 CORS 请求。

  • 在数据库中创建表，您可以在其中管理授权域列表
  • 添加该表记录“x.com”
  • 在 api.x.com 中添加请求过滤器/拦截器您使用的任何技术术语，该方法应在处理请求后调用，并在Access-Control-Allow-Origin: x.com请求来自 x.com 时添加响应（换句话说，检查请求标头引用值匹配到上表中的任何值并将该值放入 Access-Control-Allow-Origin 响应标头中）。

就是这样 :) 在此之后，如果您知道如何使用$http或jQuey.ajax，您将能够在几分钟内从任何授权域向 api.x.com 发出任何请求。

于 2013-04-23T22:39:46.150 回答
0

我使用 vinilla js web 应用程序和跨域身份验证到 GAE 后端或 OpenID 连接的想法非常相似。

Web 应用程序在 CDN 上运行。单击登录链接时，它会转到相应的登录服务器并重定向回 Web 应用程序（使用 XSRF 安全令牌和仅 HTTPS cookie）。登录服务器接受带有凭据的跨域请求。必须在每个请求中设置 XSRF 令牌（在标头中）。cookie 由浏览器设置。由于它是 HTTP only cookie，JS 无法读取它。该技术非常安全。

登录后，您可以从登录服务器获得安全评估。

有关详细说明，您可以在此处找到并在此处找到开源repo。

于 2013-04-29T01:35:04.460 回答