问题描述
考虑一个API，该API可以直接由客户端访问（机器对机器），并且不需要用户特定的身份验证。据我了解，在client_credentials中，客户端必须存储用于获取和刷新令牌的client_id和client_secret。使用API密钥，客户端仅存储密钥。在这种情况下，什么使OAuth更安全？在我看来，如果永不破坏API密钥，则不会有攻击者伪装成预期的客户端。而且，如果API密钥遭到破坏，则实际上与破坏client_id和client_secret相同，攻击者将可以使用它们来获取令牌并访问API中的数据，并伪装成客户。
编辑：阐明这是机器对机器的调用
解决方法
TLDR;
区别在于直接访问与委派访问。
OAuth允许您进行委派访问。不管是否有用户参与，委托访问的好处都不会改变。使OAuth授权代码流吸引用户到计算机的相同参数也适用于OAuth客户端凭据流，以进行计算机对机器的访问。
问问自己，您是否希望资源服务器处理客户端凭据？
在用于机器对机器访问的机密客户端上，委派访问与直接访问的成本可能会大大超过收益。这就是为什么如此多的API仍使用API密钥的原因。您必须根据自己的用例来决定。
差异
在OAuth客户端凭据流中，客户端向资源服务器发送访问令牌，该访问令牌是在提供客户端ID和密码后由授权服务器预先获得的。资源服务器永远不会看到客户端机密。使用API密钥，客户端将在每次请求时发送密钥。
OAuth在授权服务器上添加了一个附加的间接层，以使凭据本身永远不会传输到资源服务器。这允许授权服务器仅在有限的时间内或以有限的权限授予客户端访问权限，而无需更改实际的客户端凭据。它还允许撤销访问令牌，而无需撤销凭据本身。对于客户端的多个实例，这使您可以撤消某些（但不是全部）访问权限。
当然，这一切都是以更复杂的实现为代价的，并且要从客户端到授权服务器进行额外的往返。
我不会涉及传输（URL，标头，正文等）或格式（随机字符串，签名的JWT等），因为访问令牌和API密钥可以相同。
OAuth的另一个优势，也许不是那么明显，它具有一个明确的规范，可以作为库，文档和讨论的基础。对于直接访问，没有唯一的最佳实践，并且在引用诸如API密钥之类的直接访问方法时，不同的人可能会理解不同的事物。
,OAuth客户端凭据流
API密钥与OAuth的客户端凭据流之间的安全性区别是什么？
OAuth客户端凭据流并不意味着公共客户端只能在计算机之间使用。
客户凭证流
使用后端上运行的CLI（CLI），守护程序或服务等机器对机器（M2M）应用程序，系统将对应用程序（而不是用户）进行身份验证和授权。对于这种情况，典型的身份验证方案（如用户名+密码或社交登录名）没有意义。相反，M2M应用使用客户端凭据流（在OAuth 2.0 RFC 6749中的第4.4节中定义），在其中传递其客户端ID和客户端密钥进行身份验证并获得令牌。
所以，我不确定您的情况如何，但是我会在答复中假设您指的是公共客户。
如果在公共客户端代码中，则为公共
按照我的理解，在client_credentials中，客户端必须存储用于获取和刷新令牌的client_id和client_secret。
是的，它需要存储在客户端代码中，以便客户端能够获取OAuth令牌。
如果您通过网络应用程序或移动应用程序使用client_secret，则将其公开，因此不再是秘密。
从公共客户那里提取秘密
例如，在Web应用程序中，提取client_secret所需要做的就是在浏览器中点击F12并进行搜索，因此这需要多少时间？
现在，在移动应用中，有些人可能认为它是安全的，因为它们被编译成二进制文件，但几乎与在浏览器中一样简单，因为我们有几个开源工具可以帮助我们完成此任务，例如MobSF框架，在Linux上，您甚至可以使用strings命令来实现。使用MobSF对移动应用程序二进制文件执行静态二进制文件分析，使任何不懂知识的人都可以在几分钟内轻松提取client_secret，就像我在文章How to Extract an API key from a Mobile App with Static Binary Analysis中所展示的一样：
可用于逆向工程的开放源代码工具的范围非常广泛，我们在本文中确实无法涉及本主题的内容，但是，我们将专注于使用Mobile Security Framework(MobSF)来演示如何对我们的移动应用的APK进行反向工程。 MobSF是开放源代码工具的集合，可以在引人注目的仪表板中显示其结果，但是可以单独使用MobSF和其他地方使用的相同工具来获得相同的结果。
因此，在我的文章中提取api-key的过程与在移动应用程序二进制文件中提取client_secret或您感兴趣的任何其他字符串的过程相同。
OAuth或API密钥？
在这种情况下，什么使OAuth更安全？在我看来，如果永不破坏API密钥，则不会有攻击者伪装成预期的客户端。而且，如果API密钥被盗用，它实际上与破坏client_id和client_secret相同，攻击者将可以使用该密钥来获取令牌并以假冒客户端的身份访问API中的数据。
如果从公共客户端使用它也不是安全的，因为如果阅读我的链接文章，您现在已经了解绕过API密钥或提取client_secret和client_id是多么容易。
因此，如果您的客户端是公开的，则不应使用OAuth客户端凭证流程，因此，您需要使用不安全的API密钥方法，或者您可以更加勤奋地尝试应用纵深防御方法，但这将取决于API客户端是仅Web应用程序还是移动应用程序，或者两者都是。
如果您的API客户端只是Web应用程序，我邀请您阅读my answer，以解决问题从应用程序调用中保护API数据 ，尤其是专门用于保护API服务器的部分
如果API客户端只是移动应用程序，那么我建议您阅读this answer我提出的问题如何保护移动应用程序的API REST？，尤其是这些部分保护API服务器和可能的更好解决方案。
另一方面，如果您的API客户端既是Web应用程序又是移动应用程序，我建议您从上面链接的两个答案中应用与您更相关的安全措施。
请记住，安全性总是要添加尽可能多的防御层，这是法律要求的。即使在上个世纪，这些城堡也建有许多不同的安全防御层，因此对于数字时代而言，这并不是什么新鲜事。
您想走多远吗？
在回答安全问题时，我总是喜欢引用OWASP基金会的出色工作。
对于APIS
OWASP API安全项目旨在通过强调不安全API中的潜在风险并说明如何减轻这些风险来为软件开发人员和安全评估人员提供价值。为了实现此目标，OWASP API安全项目将创建和维护“十大API安全风险”文档，以及用于创建或评估API的最佳实践的文档门户。
对于移动应用
OWASP Mobile Security Project - Top 10 risks
OWASP移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制措施，以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide：
移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。
对于Web Apps
The Web Security Testing Guide：
,OWASP Web安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架，以及描述了用于测试最常见的Web应用程序和Web服务安全问题的技术的“低水平”渗透测试指南。
使用客户端凭据流，您的客户端ID和客户端密钥将发送到授权服务器以获取访问令牌。对于对API /资源服务器的所有后续请求，您传递访问令牌，而不传递客户端凭据本身。访问令牌通常是JWT，是一组编码的声明，其中包括令牌到期（exp，而不是（nbf），令牌发行者（iss），授权方（ azp），角色，权限等
与简单的API密钥方法相比，它具有许多优点。例如
- 如果访问令牌（包含在对API /资源服务器的请求中）被盗用，则它仅在到期之前有效（通常是M2M令牌的一天）。如果API密钥遭到破坏，则可以无限期使用它，例如直到被API /资源服务器明确阻止为止。 JWT访问令牌包含许多可用于细粒度授权的声明，例如：角色，权限，授予类型，授权方等。关于身份验证，API密钥通常是全部或全部。
- 您的计算机令牌可以像用户令牌一样在API /资源服务器上得到验证和授权，因此您不会在后端获得多种身份验证实现。