使用OAuth2.0保护Web Api

Question

我已经了解到OAuth 2.0委派了访问控制。我想在这里问一下OAuth2.0客户端凭据授权流程（http://oauthlib.readthedocs.io/en/latest/oauth2/grants/credentials.html） 。当我读到这个流程时，它允许客户端应用程序在目标服务（web api）的控制下（客户端应用程序拥有的资源）访问资源。例如，在Google服务的情况下 - 客户端应用程序可能想要检索拥有的Blob数据由Google Blob Storage提供。

但我看到有人使用此流程进行客户端和服务应用程序之间的身份验证（而非授权）。例如有一个Web API，它为一些公开的数据提供服务，而不是由特定的客户端APP拥有。而这项服务只能由少数众所周知的客户端应用程序来调用。 （因此，新客户端应用程序在获得访问权之前需要经过适当的入门过程）。

因此，在这种情况下，易于使用OAuth 2.0客户端凭证流程。或者仅当客户端应用程序想要访问自己的资源时才适用。

Answer 1

为了您的目的，可以使用Client Credentials Flow，但是Basic Authentication更简单。您不必使用OAuth 2.0。

但是，请记住，如果客户端应用程序不能保持客户端凭证两种解决方案不应该使用（= CLIENT_ID和OAuth 2.0用户境客户端秘密，API密钥和API秘密基本身份验证上下文）机密。以下是摘自RFC 6749,4.4. Client Credentials Grant的摘录。

客户端凭证授予类型务必只能用于机密客户端。

可以在RFC 6749找到机密客户的定义。

---

加了注释：

蛮力攻击可能会无论你使用基本身份验证或OAuth的。关于可扩展性，（1）检查一对API密钥和秘密的有效性和（2）检查访问令牌的有效性之间没有很大区别。

您可以在OAuth 1.0（RFC 5849）中找到“请求签名”的概念，但规范已废弃。有些人仍然认为OAuth 1.0在安全性方面优于OAuth 2.0，但应该注意的是，OAuth 1.0的安全性依赖于嵌入在客户端应用程序中的密钥可以保密的假设。但是，这个假设是天真的。有关“How is OAuth 2 different from OAuth 1?”的问题，请参阅my answer。

OpenID Connect，一个相对较新并建议规范，定义了一个请求的签名和加密，太。您可以在OpenID Connect Core 1.0的“6. Passing Request Parameters as JWTs”中找到它。