基于 RESTful API 的 API 密钥与 HTTP 身份验证与 OAuth

我正在为我维护的一个应用程序构建一个 RESTful API。我们目前正在寻求在其中建立各种东西，需要更多的控制访问和安全。在研究如何保护 API 时，我发现了一些关于使用什么表单的不同意见。我看到一些资源说 HTTP-Auth 是最好的选择，而其他人更喜欢 API 密钥，甚至其他人(包括我在这里找到的关于 SO 的问题)都对 OAuth 发誓。

Then, of course, the ones that prefer, say, API keys, say that OAuth is designed for applications getting access on behalf of a user (as I understand it, such as signing into a non-Facebook site using your Facebook account), and not for a user directly accessing resources on a site they've specifically signed up for (such as the official Twitter client accessing the Twitter servers). However, the recommendations for OAuth seem to be even for the most basic of authentication needs.

那么，我的问题是——假设这一切都是通过 HTTPS 完成的，那么这三者之间有哪些实际的区别呢？什么时候应该考虑一个人而不是其他人？

44180 次浏览
小开

这取决于你的需要。你需要:

  • Identity – who claims to be making an API request?
  • 认证——他们真的是他们所说的那样吗？
  • 授权-是否允许他们做他们正在尝试做的事情？

还是三个都要？

如果您只是需要识别调用者来跟踪 API 调用的数量或容量，那么可以使用一个简单的 API 键。请记住，如果您发布的 API 密钥的用户与其他人共享它，他们也将能够调用您的 API。

但是，如果您也需要 Authorization，也就是说您需要根据 API 的调用者仅提供对某些资源的访问，那么使用 oAuth。

这里有一个很好的描述: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

小开

API 密钥甚至令牌属于直接身份验证和授权机制的范畴，因为它们授予对 REST API 的公开资源的访问权。这样的直接机制可以在委托用例中使用。

In order to get access to a resource or a set of resources exposed by REST endpoints, it is needed to check the requestor privileges according to its identity. First step of the workflow is then verifying the identity by authenticating the request; successive step is checking the identity against a set of defined rules to 授权 the level of access (i.e. read, write or read/write). Once the said steps are accomplished, a typical further concern is the allowed 请求比率请求比率, meaning how many requests per second the requestor is allowed to perform towards the given resource(s).

OAuth (Open Authorization) is a standard protocol for 授权访问, often used by major Internet Companies to grant access without providing the password. As clear, OAuth is protocol which fulfils the above mentioned concerns: Authentication and Authorization by providing secure delegated access to server resources on behalf of the resource owner. It is based on access Tokens mechanism which allow to the 3rd party to get access to the resource managed by the server on behalf of the resource owner. For example, ServiceX wants to access John Smith's Google Account on behalf of John, once John has authorized the delegation; ServiceX will be then issued a time-based Token to access the Google Account details, very likely in read access only.

API Key 的概念非常类似于上面描述的 OAuth 令牌。主要区别在于没有委托: 用户直接请求服务提供者的密钥以进行连续的编程交互。API Key 的情况也是基于时间的: 作为 OAuth 令牌的 Key 受到时间租约或有效期的限制。 另外，钥匙和令牌可能受到服务合同的费率限制，即每秒只能提供给定数量的请求。

简而言之，实际上，传统的身份验证和授权机制与基于密钥/令牌的版本之间并没有真正的区别。但是范例稍有不同: 在客户机和服务器之间的每一次交互中，不再重复使用凭据，而是使用了一个支持 Key/Token，这使得整个交互体验更加流畅，可能更加安全(通常，遵循 智威汤逊标准，服务器对密钥和令牌进行数字签名，以避免制作)。

  • 直接身份验证和授权 : 基于密钥的协议是传统的基于凭证的版本的一个变体。
  • 委托身份验证和授权 : 与基于 OAuth 的协议类似，后者依次使用令牌，同样也是基于凭证的版本的变体(总体目标是不向任何第三方披露密码)。

Both categories use a traditional identity verification workflow for the very first interaction with the server owning the interested resource(s).


提交答案