我已经了解到OAuth 2.0是委派的访问控制。我想在这里询问OAuth2.0客户端凭据授权流程（http://oauthlib.readthedocs.io/en/latest/oauth2/grants/credentials.html） 。当我读到这个流程时，它允许客户端应用程序从Target Service（web api）访问自己控制的资源（也就是客户端应用程序拥有的资源）。例如，在Google Services的情况下 - 客户端应用程序可能想要检索拥有的Blob数据来自Google Blob Storage。
但我看到有人使用此流程在客户端和服务应用程序之间进行身份验证（而不是授权）。例如有一个Web API，它提供一些公开的数据，而不是特定客户端APP拥有的数据。此服务只能由少数知名服务的客户端应用程序调用。 （因此，新的客户端应用程序需要在获得访问权限之前经过适当的入职流程）。
因此，在这种情况下，是否容易使用OAuth 2.0 Client Credential Flow。或者仅当客户端应用程序想要访问其自己的资源时才适用。
答案 0 :(得分：0)
出于您的目的，可以使用客户端凭据流，但 Basic Authentication 更简单。您不必使用OAuth 2.0。
但是，请记住，如果客户端应用程序无法保留客户端凭据（= OAuth 2.0上下文中的client_id和客户端密钥，以及基本身份验证上下文中的API密钥和API密钥），则不应使用这两种解决方案机密< / strong>即可。以下是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的安全性依赖于客户端应用程序中嵌入的密钥可以保密的假设。但是，这种假设是天真的。请参阅问题“my answer”的How is OAuth 2 different from OAuth 1?。
OpenID Connect ，一个相对较新且推荐的规范，也定义了请求的签名和加密。您可以在6. Passing Request Parameters as JWTs的“OpenID Connect Core 1.0”中找到它。