API 密钥和 OAuth 的客户端凭据流之间的安全区别是什么？

Question

考虑一个客户端直接访问（机器到机器）并且不需要特定于用户的身份验证的 API。我理解它的方式是client_credentials，客户端必须存储 aclient_id并且client_secret它用来获取和刷新令牌。使用 API 密钥，客户端只需存储密钥。在这种情况下，是什么让 OAuth 更安​​全？在我看来，如果 API 密钥永远不会被泄露，那么攻击者就无法伪装成预期的客户端。如果 API 密钥被泄露，它实际上与破坏client_idand相同client_secret，攻击者可以使用 and 获取令牌并访问 API 中的数据，冒充客户端。

编辑：澄清这是一个机器对机器的调用

Answer 1

通过客户端凭证流，您的客户端 ID 和客户端密钥将被发送到授权服务器以取回访问令牌。对于对 API/资源服务器的所有后续请求，您将传递访问令牌而不是客户端凭据本身。访问令牌通常是 JWT，它是一组编码的声明，包括令牌过期时间 ( exp)、不早于 ( nbf)、令牌颁发者 ( iss)、授权方 ( azp)、角色、权限等。

与简单的 API 密钥方法相比，这具有许多优点。例如

• 如果访问令牌（包含在对 API/资源服务器的请求中）被泄露，则它仅在过期之前有效（对于 M2M 令牌来说，通常约为 1 天）。如果 API 密钥遭到泄露，它可以无限期地使用，或者直到被 API/资源服务器明确阻止为止。
• JWT 访问令牌是编码的 JSON 对象，其中包含许多字段（也称为声明），可用于细粒度授权，例如角色、权限、授予类型、授权方等。 API 密钥通常是不透明的，当它存在时，要么全部要么全无。来验证。
• 您的机器令牌可以像用户令牌一样在 API/资源服务器上进行验证和授权，因此您最终不会在后端实现多个身份验证。

Answer 2

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) 是移动应用安全开发、测试和逆向工程的综合手册。

对于网络应用程序

网络安全测试指南：

OWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。

Answer 3

TLDR；

区别在于直接访问与委托访问。

OAuth 允许您进行委托访问。无论是否涉及用户，委派访问的好处都不会改变。使 OAuth 授权代码流对用户到机器访问具有吸引力的相同论点，也适用于机器到机器访问的 OAuth 客户端凭据流。

问问自己，您是否希望资源服务器处理客户端凭据？

在用于机器对机器访问的机密客户端上，委派访问与直接访问的成本可能远远超过收益。这就是为什么这么多 API 仍然使用 API 密钥的原因。您必须为您的个人用例决定。

差异

在 OAuth 客户端凭据流中，客户端向资源服务器发送访问令牌，授权服务器在提供其客户端 ID 和机密后预先获得该令牌。资源服务器永远不会看到客户端机密。使用 API 密钥，客户端会随每个请求发送密钥。

OAuth 为授权服务器添加了一个额外的间接层，这样凭据本身永远不会传输到资源服务器。这允许授权服务器仅在有限的时间内或以有限的权限授予客户端访问权限，而无需更改实际的客户端凭据。它还允许在不撤销凭据本身的情况下撤销访问令牌。对于客户端的多个实例，这允许您撤消某些但不是全部的访问权限。

当然，这一切都以更复杂的实现以及从客户端到授权服务器的额外往返为代价。

我不会涉及传输（URL、标题、正文等）或格式（随机字符串、签名的 JWT 等），因为这些对于访问令牌和 API 密钥来说是相同的。

OAuth 的另一个可能不那么明显的优势是有一个明确的规范，库、文档和讨论都可以以此为基础。直接访问没有单一的最佳实践，当提到 API 密钥等直接访问方法时，不同的人可能会理解不同的东西。