使用带有本地策略的 CORS 向 REST API 验证客户端应用程序 [英] Authenticate client-side app to REST API using CORS with local strategy

问题描述

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

Serving a secure API to a client side app using only a local authentication strategy.
The red arrows are part of the knowledge gap.

即 --- client.example.com 正在向 api.example.com/login 发送 POST 到成功 client.example.com 可以访问 GET 服务，例如 api.example.com/secret.

That is --- client.example.com is making a POST to api.example.com/login where on success client.example.com can gain access to a GET service like api.example.com/secret.

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

Implimentation of OAuth 2.0 with hybrid grant type sitting in front of API.

为什么要混合?

• 它不会是 Implicit Grant Flow aka Client-Side Web Applications Flow 因为没有重定向到 API 服务器也授予访问令牌.(即)某某人可以访问您的数据吗?"

• It wouldn't be an Implicit Grant Flow aka Client-Side Web Applications Flow because there is no redirection to API server too grant access token. (i.e.) "Is it ok for so-and-so to access your data?"

它不会是 Resource Owner Password Flow，因为 Client ID 和 Client Secret 与请求一起传递，因此假定客户端应用程序是服务器端.

It wouldn't be a Resource Owner Password Flow because a Client ID and Client Secret are passed along with the request so it's assumed the client app is server-side.

好吧……那么两者都加一点怎么样?

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

What if we used a CRSF token on page load of client-side app, and POST it with user credentials too OAuth 2.0 authentication endpoint to exchange for access token? You would authenticate each subsequent request with the access token and CRSF token after a successful login.

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

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

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

I can not find a working example of an authentication measure that solves this problem! Point me in the right direction?

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

Ultimately, the goal here is too authenticate a client side app to a REST api using CORS with a local strategy --- i.e. username & password --- even if the convention above isn't possible.

为了提供赏金:

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

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

I'm looking for a working example using the Node.js OAuth 2.0 seed above for the API/Auth server and a front end framework like Angular.js or Backbone.js to make requests.

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

推荐答案

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

I'm working on an app with a pretty similar architecture though the services are .NET Web API rather than Node and we're using DotNetOpenAuth for the OAuth provider. Rather than the hybrid approach you're suggesting we're doing the following:

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 调用以获取新的访问令牌

1. x.com serves up a login page
2. login page POSTs back credentials to x.com
3. server side logic at x.com combines client_id and client_secret with the credentials to submit a token request (resource owner password credentials grant that you've mentioned above) receiving back both a temporary access token and a refresh token
4. the refresh token is encrypted into a cookie issued by x.com
5. both the cookie (with encrypted refresh token) and the temporary access token are then sent to the browser
6. the client app (angular in my case) can now use the access token to hit api.x.com for services (It appears you're well aware of the limitations of CORS... we hacked a version of angular's $resource to facilitate this but it wasn't pretty since we wanted to use all HTTP verbs and support IE9)
7. when the access token expires, the client side app can request a new access token from x.com
8. server-side, x.com decrypts the cookie to get at the refresh token and issues another oauth call for a new access token

这是相当高级的，但希望能让您了解如何解决您的情况.在我的情况下，它出现在你的情况下，我们不想使用会话状态或数据库来存储刷新令牌，但显然将其暴露给浏览器会引入安全问题，因此刷新令牌的加密很重要(在其他安全性中)考虑)并且使用 cookie 消除了 x.com 上会话状态或其他持久存储的需要.

This is fairly high-level but hopefully gives you a sense for how to tackle your situation. In my case, and it appears in yours, we didn't want to use session state or a database to store the refresh token but obviously exposing that to the browser introduces security concerns so the encryption of the refresh token is important (among other security considerations) and the use of the cookie eliminates the need for session state or other persistent storage on x.com.

这篇关于使用带有本地策略的 CORS 向 REST API 验证客户端应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！