在什么地方登录对话框3条腿验证了宁静的API [英] Where to place login dialog for 3-legged Auth for restful API

问题描述

我想换我的头约3条腿的认证，以确保一个宁静的API。

目前我在app.host.com需要由多个用户使用不同的帐户权限和数据，以及其在app_api.host.com

有关3条腿的权威性，我明白，我首先需要一个消费者密钥和秘密属于客户app.host.com ......我也明白一个未经授权的请求令牌必须由服务提供商，这是考虑到提供在客户端，然后将其重定向回服务提供者的授权与一个登录对话框

因此​​，没有登录对话框中存在，那么作为app_api.host.com的API主机上的用户界面？这难道不是打败我的目的，单独建立一个纯粹的JSON API宁静给客户？

或者，我可以建立客户端，然后这将发布用户/密码信息给另一台auth端点的API，并提供了200 code的请求令牌被授权在登录对话框？再依次客户会要求从用户权限，这将再次被张贴到另一个端点，然后用该用户相应的访问令牌？

响应

TL; DR：我是否能够有登录对话框存在于客户端上，然后张贴数据到服务提供商？我读过的所有指南建议其服务提供商，在这种情况下将完全打败具有API作为一个单独的应用程序的目的对话框。我应该如何去建立呢？任何可用的导游？

解决方案

的OAuth 2.0 定义了不同的流量使用与不同的客户端，这取决于你有多少信任客户端。

授权code

第一个和最secury流是授权令牌流。它是用来与您可以在其中存储机密信息安全比较（仅拥有管理员权限应该可以访问存储在配置客户端ID和密码）传统的web应用程序。

当用户（资源所有者）要进行身份验证，用户代理重定向到属于资源服务器的域（客户端要消耗数据，例如Facebook或谷歌）授权服务器。授权服务器presents与登录UI用户。当用户成功验证，这presents同意UI询问用户是否希望客户端应用程序访问资源。如果用户同意，用户代理重定向回一个授权code中的客户端应用程序。客户端应用程序现在可以使用此code，其客户端ID和秘密的直接对话授权服务器，并得到一个访问令牌。在该流程中，访问令牌是从来没有在用户代理的手中。

隐流程

在隐式流程中，用户代理（通常是在这里土生土长的（移动）应用程序或JavaScript客户端）重定向到授权服务器，或打开浏览器窗口导航到授权服务器。当用户成功地和授予权限的客户端应用程序进行认证，接入令牌本身被返回到客户端。因此，用户代理永远不会看到用户输入（如出现这种情况是由资源服务器控制的HTML页）的用户名和密码，但确实有过访问令牌控制。

资源所有者密码凭据流程

下面的用户代理是完全可信的，并询问用户名和密码。它再与授权服务器以获得访问令牌通信。即使用户代理知道用户的凭据，它仅使用一次即可获得一个访问令牌。它不需要沿各请求到资源服务器发送它们。

因此​​，要回答你的问题，你可以建立的登录对话框中您的应用程序，如果你认为你的用户会信任你的应用程序，足以给你他们的凭据。否则，你也许应该去为其他流之一。你可以阅读更多的OAuth的2 这里和的这里。

I'm trying to wrap my head around 3-legged authentication to secure a restful API.

Currently I have a client application at app.host.com which needs to be accessed by multiple users with different account permissions and data, as well as the JSON RESTful api which holds all data at app_api.host.com

For 3-legged auth, I understand I first need a consumer key and secret belonging to the client app.host.com... I also understand an unauthorized request token must be provided by the service provider, which is given to the client, which is then redirected back to the service provider for authorization with a login dialog.

So does the login dialog then exist as a user interface on the API host at app_api.host.com? Doesn't this defeat the purpose of me building a purely JSON restful API separately to the client?

Or can I build the login dialog on the client which would then post the user/pwd details to another auth endpoint on the API and provide a 200 code when the request token is authorized? And then in turn the client would ask for permissions from the user which would again be posted to another endpoint which then responds with the appropriate access token for that user?

TL;DR: Am I able to have the login dialog exist on the client, which then posts data to the service provider? All guides I've read suggest having the dialog on the service provider, which in this case would defeat the purpose of having the api as a separate app altogether. How should I go about building this? Any available guides?

解决方案

OAuth 2.0 defines different flows to use with different clients, depending on how much you trust the client.

Authorization code

The first and most secury flow is the authorization token flow. It is used with a traditional web application in which you can store secrets relatively securely (only people with admin privileges should have access to the client ID and secret stored in the configuration).

When the user (resource owner) wants to authenticate, the user-agent is redirected to the authorization server which belongs to the domain of the resource server (the data the client wants to consume, for example Facebook or Google). The authorization server presents the user with logon UI. When the user authenticates successfully, it presents the consent UI to ask if the user wants the client application to access the resource. If the user consents, the user-agent is redirected back to the client application with an authorization code. The client application can now use this code, its client ID and secret to talk to the authorization server directly and get an access token. In this flow, the access token is never in the hands of the user-agent.

Implicit flow

In the implicit flow, the user-agent (here typically a native (mobile) application or JavaScript client) redirects to the authorization server or opens a browser window to navigate to the authorization server. When the user authenticates successfully and grants permission to the client application, the access token itself is returned to the client. So the user-agent never sees the username and password the user enters (as this happens on a HTML page that is controlled by the resource server), but does have control over the access token.

Resource owner password credential flow

Here the user-agent is fully trusted and asks the user for username and password. It then communicates with the authorization server to get a access token. Even though the user-agent knows the credentials of the user, it only uses them once to get an access token. It does not need to send them along each request to the resource server.

So to answer your question, you can build the login dialog in your app if you think your users will trust your application enough to give you their credentials. Otherwise you should probably go for one of the other flows. You can read more on OAuth 2 here and here.

这篇关于在什么地方登录对话框3条腿验证了宁静的API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！