通过安全令牌进行 API 身份验证的最佳实践（Node.js 服务器和移动应用程序）

Question

通常我们通过 JWT（访问和刷新令牌）保护移动 API。但我们刚刚面临这样的情况：即使 JWT 令牌过期，我们的应用程序也必须 100% 可供用户使用。（这是一些紧急的事情）。用户/应用程序不能等待重新登录并获取新的 JWT 代码。

问题：长时间（...永远）保护 API 调用而不从后端获取新令牌的最佳方法是什么。当每个请求使用每个请求的当前日期时间附件对移动应用程序进行共享密钥加密时，我看到了几次变体...但我不确定这是一个好的解决方案，至少它会存在性能问题（加密的操作时间） /解密请求）。

Answer 1

API 用户 JWT 令牌

通常我们通过 JWT（访问和刷新令牌）保护移动 API。用户/应用程序不能等待重新登录并获取新的 JWT 代码。

这只允许您的 API 服务器知道谁在请求中，而不知道是什么在执行请求。

WHO 和 WHAT 之间的区别是访问 API 服务器

我撰写了一系列有关 API 和移动安全的文章，并在文章《为什么您的移动应用程序需要 Api 密钥？》中 您可以详细阅读谁和什么正在访问您的 API 服务器之间的区别，但我将在这里提取其中的要点：

向 API 服务器发出请求的是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动探查您的 API 服务器？

我们可以通过多种方式（例如使用 OpenID Connect 或 OAUTH2 流）对移动应用程序的用户进行身份验证、授权和识别。

因此，将“谁”视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将“什么”视为代表用户发出该请求的软件。

你的问题

但我们刚刚面临这样的情况：即使 JWT 令牌过期，我们的应用程序也必须 100% 可供用户使用。（这是一些紧急的事情）。

您发现自己遇到了一个非常具有挑战性的问题，但并非不可能，我们开发人员喜欢这种类型的挑战:)。

传入请求

到目前为止，我希望您已经很好地理解了谁和什么正在访问您的 API 服务器之间的区别，因此您可能已经意识到您不能绝对信任到达您的 API 服务器的任何请求。因此，您必须将任何请求视为对您的 API 服务器的潜在攻击，直到有相反的证据为止，就像您在法庭上是无辜的，直到有相反的证据为止；）。

请求加密

但我不确定这是否是一个好的解决方案，至少它会存在性能问题（加密/解密请求的操作时间）。

就像您去餐厅时不能指望免费晚餐一样，您不能指望在不增加几毫秒的应用时间的情况下为任何应用程序添加安全性;)。

当每个请求使用移动应用程序的共享密钥进行加密以及每个请求的当前日期时间附件时，我看到了几次变体......

这种方式更适合保证请求中数据的完整性。换句话说，中间人 (MitM) 攻击无法看到或修改它，但不会向 API 服务器提供任何保证，该服务器确实来自您所期望的移动应用程序，因为攻击者可以抓住来自您的移动应用程序的真实请求并重播。

另外，攻击者可以使用静态二进制分析对您的移动应用程序进行逆向工程，以提取加密密钥，方法类似于我在如何使用静态二进制分析 从移动应用程序中提取 API 密钥一文中演示的方法：

可用于逆向工程的开源工具种类繁多，在本文中我们确实无法触及这个主题的表面，但我们将重点关注使用移动安全框架（MobSF）来演示如何对我们的移动应用程序的 APK。MobSF 是开源工具的集合，它们在有吸引力的仪表板中展示其结果，但是 MobSF 和其他地方在幕后使用的相同工具可以单独使用以实现相同的结果。

如果静态分析的逆向工程不起作用，那么攻击者可以使用仪器框架在运行时挂钩到您的移动应用程序并提取用于加密请求的密钥，因此他将能够生成自己的请求并进行您的 API 服务器认为发出请求的是您的移动应用程序，而实际上是攻击者现在拥有了加密密钥。

Frida是仪器框架的一个很好的例子：

将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。

证明 API 请求可信

问题：长时间（...永远）保护 API 调用而不从后端获取新令牌的最佳方法是什么。

我希望现在您已经意识到，通过使用一系列可用的逆向工程技术和开源工具，攻击者一直想探查您的移动应用程序，以了解其强化技术以及如何绕过它们来攻击您的移动应用程序。将您的 API 服务器模拟成它真正期望的那样，即您的移动应用程序。最重要的是，您无法使用移动应用程序内附带的静态解决方案“永远”保护您的 API 服务器。

保护 API 服务器并不是一件容易的事，您应该在您的市场上应用您可以负担得起且法律要求的尽可能多的安全层。

您的问题的一个可能的解决方案是应用移动应用程序证明概念，您可以在我给出的另一个问题的答案Securing the API Server中阅读更多相关内容，我建议您特别注意和部分A Possible Better Solution。

您想加倍努力吗？

在对安全问题的任何回答中，我总是喜欢参考 OWASP 基金会的出色工作，因此这个答案也不例外:)

对于移动应用程序

OWASP 移动安全项目 - 十大风险

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

OWASP - 移动安全测试指南：

移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。

对于APIS

OWASP API 安全性前 10 名

OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建并维护十大 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。