考虑一个客户端直接访问(机器对机器)的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密钥等直接访问方法时，不同的人可能会理解不同的东西。
通过客户端凭据流，您的客户端Id和客户端机密将被发送到授权服务器以获取访问令牌。对于API/资源服务器的所有后续请求，您传递访问令牌，而不是客户端凭据本身。访问令牌通常是JWT，它是一组编码声明，包括令牌到期(exp)、不在此之前(nbf)、令牌颁发者(iss)、授权方(azp)、角色、权限等。
与简单的API密钥方法相比，这具有许多优点。例如
- 如果访问令牌(包含在对API/资源服务器的请求中)被泄露，则其仅在到期之前有效(M2M令牌通常为约1天)。如果API密钥被泄露，它可以无限期使用，或者直到它被API/资源服务器明确阻止
- JWT访问令牌是编码的JSON对象，包含许多可用于细粒度授权的字段(也称为声明)，例如角色、权限、授予类型、授权方等。API密钥通常是不透明的，在授权时是全有或无的
- 机器令牌可以在API/资源服务器上以与用户令牌相同的方式进行验证和授权，因此不会在后端出现多个身份验证实现
OAuth客户端凭据流
API密钥和OAuth的客户端凭据流之间的安全性差异是什么？
OAuth客户端凭据流并不意味着由公共客户端使用，只是在机器之间使用。
来自auth0.com/docs:
客户端凭据流
对于机器对机器(M2M)应用程序，如在后端运行的CLI、守护程序或服务，系统会对应用程序而不是用户进行身份验证和授权。对于这种情况，典型的身份验证方案(如用户名+密码或社交登录)没有意义。相反，M2M应用程序使用客户端凭据流(在OAuth 2.0 RFC 6749第4.4节中定义)，在该流中，它们传递客户端ID和客户端密钥来对自己进行身份验证并获得令牌。
所以，我不确定你的情况是什么，但我会在回复中假设你指的是公共客户。
如果它在公共客户端代码中，那么它就是公共的
按照我的理解，在client_credentials中，客户端必须存储用于获取和刷新令牌的client_id和client_secret。
是的，它需要存储在客户端代码中，以便客户端能够获得OAuth令牌。
如果你从网络应用程序或移动应用程序中使用client_secret，你就是在公开它，因此不再是秘密。
从公共客户端提取机密
例如，在一个网络应用程序中，提取client_secret只需要在浏览器中点击F12并搜索它，那么这需要多少时间？
现在，在移动应用程序中，有些人可能认为它是安全的，因为它们被编译成二进制文件，但几乎和在浏览器中一样容易，因为我们有几个开源工具可以帮助我们完成这项任务，比如MobSF框架，在Linux上，你甚至可以通过strings命令来实现这一点。使用MobSF对移动应用程序二进制文件进行静态二进制分析，可以让任何没有黑客知识的人在几分钟内轻松提取client_secret，就像我在文章《如何使用静态二进制分析从移动应用程序提取API密钥：》中展示的那样
可用于反向工程的开源工具范围很大，我们在本文中确实无法触及这个主题的表面，但我们将重点使用移动安全框架(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应用程序，我邀请您阅读我对以下问题的回答从应用程序外的调用中保护API数据，特别是专门用于保护API服务器的部分。
在API客户端仅为移动应用程序的情况下，我建议您阅读我对问题的回答如何确保移动应用程序使用API REST，特别是保护API服务器和可能的更好解决方案部分。
另一方面，如果您的API客户端既是网络应用程序又是移动应用程序，我建议您应用上面链接的两个答案中与您更相关的安全措施。
请记住，安全始终是指添加尽可能多的防御层，或者是法律要求的。即使在过去的一个世纪里，这些城堡也有很多不同的安全防御层，因此这对数字时代来说并不是什么新鲜事。
你想多跑一英里吗
在回答安全问题时，我总是喜欢引用OWASP基金会的出色工作。
对于APIS
OWASP API安全前10名
OWASP API安全项目旨在通过强调不安全API中的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API安全项目将创建并维护API十大安全风险文档，以及创建或评估API时最佳实践的文档门户。
适用于移动应用程序
OWASP移动安全项目-十大风险
OWASP移动安全项目是一个集中的资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供开发控制，以减少其影响或被利用的可能性。
OWASP-移动安全测试指南：
《移动安全测试指南》(MSTG)是一本关于移动应用程序安全开发、测试和逆向工程的综合手册。
适用于Web应用程序
网络安全测试指南：
OWASP Web安全测试指南包括一个"；最佳实践"；用户可以在他们自己的组织中实现的渗透测试框架；低电平"；渗透测试指南，描述了测试最常见的web应用程序和web服务安全问题的技术。