api - 通过安全令牌进行 API 身份验证的最佳实践（Node.js 服务器和移动应用程序）
问题描述
通常我们通过 JWT（访问和刷新令牌）保护移动 API。但是我们只是面临这样的情况，即我们的应用程序必须 100% 可供用户使用，即使 JWT 令牌已过期。（它是一些紧急的东西）。并且用户/应用程序不能等待重新登录并获得新的 JWT 代码..
问题：在不从后端获取新令牌的情况下，长时间（...永远）保护 API 调用的最佳方法是什么。当每个请求使用共享密钥对移动应用程序进行加密时，我看到了几次变体，每个请求的当前日期时间附件......但我不确定它是否是一个好的解决方案，至少它会有性能问题（加密的操作时间/解密请求）。
解决方案
API 用户 JWT 令牌
通常我们通过 JWT（访问和刷新令牌）保护移动 API。并且用户/应用程序不能等待重新登录并获得新的 JWT 代码..
这只允许您的 API 服务器知道谁在请求中，而不是在做什么。
访问 API 服务器的 WHO 和 WHAT 之间的区别
我写了一系列关于 API 和移动安全的文章，在文章为什么你的移动应用需要 Api Key？您可以详细阅读访问您的 API 服务器的Who和What之间的区别，但我将在此处提取其中的要点：
向 API 服务器发出请求的内容是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
因此，将谁视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将其视为代表用户发出该请求的软件。
你的问题
但是我们只是面临这样的情况，即我们的应用程序必须 100% 可供用户使用，即使 JWT 令牌已过期。（它是一些紧急的东西）。
您发现自己需要解决一个非常具有挑战性的问题，但并非不可能，我们的开发人员喜欢这种类型的挑战 :)。
传入请求
到目前为止，我希望您已经很好地理解了访问您的 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 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
对于 APIS
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了促进实现这一目标，OWASP API 安全项目将创建和维护一个前 10 名 API 安全风险文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。