HTTP基本认证+访问令牌？ [英] HTTP Basic Authentication + Access Token?

问题描述

我开发一个REST API，我打算用网络和iOS应用使用。我打算这个API是私有的某个时候（私人的意思，我只希望我的web应用程序和iOS应用访问API）。

I am developing a REST API that I plan on using with a web and IOS app. I intend for this API to be private for sometime (private meaning I only want my web app and ios app to access the api).

我看过很多不同的身份验证方法，但我仍然迷茫，选择我的API合适的身份验证方法。

I have read about many different authentication methods but I am still to confused to select the appropriate authentication method for my API.

据我了解，是的oauth2允许用户使用其他服务供应商登录到您的应用程序，让您可以访问相应的服务供应商的数据。我访问的数据在我自己的API，所以我相信这并不适用于我？

From what I understand, oAuth2 is for allowing users to login to your APP using other service providers so that you can access the data on the respective service provider. I am accessing the data in my own API so I believe this does not apply to me?

所以，这里是我在想什么：

So, here is what I am thinking:

• 1）使用HTTP基本身份验证发送用户名/密码给服务器。

• 1) Use HTTP Basic Authentication to send the user/pass to the server.

2）一旦服务器验证的登录，返回一个访问令牌将在x小时后过期。这将允许我简单地存储令牌而不是用户名/密码凭据。

2) Once the server validates the login, return an access token that will expire in x hours. This will allow me to simply store the token rather than the user/pass credentials.

我已经Google'd这种技术并没有真正找到这个方法，它使我相信这不是一个好办法，我可能会被试图重塑任何东西的信息？

I have Google'd this technique and haven't really found any info on this method which leads me to believe this is not a good way as I may potentially be trying to reinvent something?

我应该怎么做？就是我要找的双向OAuth？

What should I be doing? Is what I am looking for two-legged oAuth?

推荐答案

OAuth 2.0用户已成为首选的协议，以确保网络的API。它需要用户授权应用程序访问您的Web API。

OAuth 2.0 has become the protocol of choice to secure web API's. It requires a user to authorize an application to access your web API.

您想您的应用程序是可以访问某些API的唯一的一个。 OAuth 2.0用户允许这样做。

You want your application to be the only one that can access certain API's. OAuth 2.0 allows doing just that.

在您的授权服务器，实现授权code格兰特与所需的客户端证书（不可选）。让这个只有您的应用程序（或配置的列表运算第一方应用程序）可以获取使这些API调用所需的范围。只要你保持你的客户端密钥秘密的确，你的应用程序将是唯一一个能够获得访问令牌所要求的范围。在Web API，保证的范围被授予用于调用API的访问令牌。

In your authorization server, implement the Authorization Code Grant with client credentials required (not optional). Make it so that only your app (or a configured list op first party apps) can acquire the scope required to make those API calls. As long as you keep your client secret a secret indeed, your app will be the only one able to get an access token with the required scope. In the web API, ensure the scope is granted to the access token used to call the API.

好授权服务器，如身份枢纽，将允许你只做到这一点。

Good authorization servers, such as The Identity Hub, will allow you to do just that.

不要使用资源所有者密码凭据授予。作为规范说：

Do not use the Resource Owner Password Credentials Grant. As the specification says:

当有一个高的凭据，才应使用
     资源所有者和客户端（之间的信任度例如，
     客户端设备操作系统或高权限的一部分
     应用程序），并且当其它授权许可类型不
     可（如授权code）。

The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).

这是重复后来：

授权服务器应特别注意，当
     启用此批类型，只允许它时，其他流不
     可行的。

The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

如果密码凭据补助是可用的，任何应用都可以通过询问用户名和密码的用户获得的令牌。这就是你不想要的东西。

If the password credentials grant is available, any application can acquire a token by asking the user for a user id and password. This is exactly what you do not want.

该规范即将固有的使用密码的问题很清楚：

在传统的客户机 - 服务器验证模型中，​​客户端
     对请求访问受限的资源​​（受保护的资源）
     服务器通过使用与服务器认证所述资源所有者的
     证书。为了提供给第三方应用程序的访问
     有限资源，资源所有者分享其凭据
     第三方。这就造成一些问题和限制

In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations

OAuth 2.0用户是专为克服一些问题与使用密码：

OAuth 2.0 was designed specifically to overcome some of the issues with using passwords:

的OAuth通过引入一个授权层解决了这些问题
     并从该资源的分离客户端的角色
     所有者。在OAuth的，客户端请求访问控制的资源
     由资源所有者和由资源服务器托管，并且是
     发出了不同的凭据比那些资源
     所有者。

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

此外，如果您的API想知道用户（除了知道客户端应用程序），它是不可能的滥用，而不是资源所有者资源所有者密码凭据授予验证客户端（即应用程序）（即用户），由弗洛朗莫塞利建议。

Furthermore, if your API wants to know the user (in addition to knowing the client app), it is impossible to abuse the Resource Owner Password Credentials Grant to authenticate the client (i.e. app) instead of the resource owner (i.e. user), as suggested by Florent Morselli.

这篇关于HTTP基本认证+访问令牌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！