考虑一个客户端直接访问（机器对机器）并且不需要用户特定身份验证的 API。按照我的理解，在client_credentials 中，客户端必须存储一个client_id 和client_secret，用于获取和刷新令牌。使用 API 密钥，客户端只需存储密钥。在这种情况下，是什么让 OAuth 更安全？在我看来，如果 API 密钥从未被泄露，那么任何攻击者都无法冒充目标客户端。如果 API 密钥被泄露，它实际上与泄露 client_id 和 client_secret 相同，攻击者可以使用它们来获取令牌并冒充客户端访问 API 中的数据。
编辑：澄清这是一个机器对机器的调用
【问题讨论】：
标签： api security oauth api-key
区别在于直接访问与委托访问。
OAuth 允许您进行委托访问。无论是否涉及用户，委派访问的好处都不会改变。使 OAuth 授权代码流对用户到机器的访问具有吸引力的相同论点，也适用于机器对机器访问的 OAuth 客户端凭据流。
问问自己，您是否希望资源服务器处理客户端凭据？
在用于机器对机器访问的机密客户端上，委托访问与直接访问的成本可能远远超过收益。这就是为什么这么多 API 仍然使用 API 密钥的原因。您必须根据您的个人用例来决定。
在 OAuth 客户端凭据流中，客户端向资源服务器发送访问令牌，授权服务器在提供其客户端 ID 和机密后预先获得该令牌。资源服务器永远不会看到客户端密码。使用 API 密钥，客户端会随每个请求发送密钥。
OAuth 为授权服务器添加了一个额外的间接层，这样凭据本身就不会被传输到资源服务器。这允许授权服务器仅在有限的时间内或以有限的权限授予客户端访问权限，而无需更改实际的客户端凭据。它还允许在不撤销凭据本身的情况下撤销访问令牌。对于一个客户端的多个实例，这允许您撤销部分但不是全部的访问权限。
当然，这一切都以更复杂的实现为代价，以及从客户端到授权服务器的额外往返。
我不会涉及传输（URL、标头、正文等）或格式（随机字符串、签名 JWT 等），因为这些对于访问令牌和 API 密钥可能是相同的。
OAuth 的另一个（可能不是那么明显）优势是有一个明确的规范，库、文档和讨论都可以基于该规范。直接访问没有单一的最佳实践，当提到 API 密钥等直接访问方法时，不同的人可能会理解不同的东西。
【讨论】：
通过客户端凭据流，您的客户端 ID 和客户端密码将被发送到授权服务器以取回访问令牌。对于对 API/资源服务器的所有后续请求，您传递访问令牌而不是客户端凭据本身。访问令牌通常是一个 JWT，它是一组编码的声明，包括令牌到期 (exp)、未到期 (nbf)、令牌颁发者 (iss)、授权方 (azp)、角色, 权限等。
与简单的 API 密钥方法相比，这具有许多优点。例如
【讨论】：
API 密钥与 OAuth 的客户端凭据流之间的安全差异是什么？
OAuth 客户端凭据流并不打算供公共客户端使用，仅用于机器之间。
客户凭证流程
对于机器对机器 (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，就像我在文章 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 密钥从未被泄露，任何攻击者都无法冒充目标客户端。如果 API 密钥被泄露，它实际上与泄露 client_id 和 client_secret 相同，攻击者可以使用它们来获取令牌并访问 API 中的数据，冒充客户端。
如果从公共客户端使用，两者都不安全，因为如果阅读我的链接文章，您现在就会明白绕过 API 密钥或提取 client_secret 和 client_id 是多么容易。
因此，如果您的客户端是公开的，则不应使用 OAuth 客户端凭据流，因此您需要使用不安全的 API 密钥方法，或者您可以更加勤奋并尝试应用深度防御方法，但这将取决于 API 客户端是否只是网络应用程序或移动应用程序或两者兼而有之。
如果您的 API 客户端只是 Web 应用程序，我邀请您阅读 my answer 以了解问题保护 API 数据免受应用程序外调用的影响，尤其是专用于保护 API 服务器的部分。
如果 API 客户端只是移动应用程序，那么我建议您阅读 this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是部分 保护 API 服务器和可能的更好解决方案。
另一方面，如果您的 API 客户端既是网络应用程序又是移动应用程序，我建议您从上面链接的两个答案中应用与您更相关的安全措施。
请记住，安全始终是在您负担得起或法律要求的情况下添加尽可能多的防御层。即使在过去的一个世纪里，城堡也建立了许多不同的安全防御层，因此这对于数字时代来说已经不是什么新鲜事了。
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是一本用于移动应用安全开发、测试和逆向工程的综合手册。
The Web Security Testing Guide:
OWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。
【讨论】：