通常我们通过JWT(访问和刷新令牌)保护移动API。但我们面临的情况是，即使JWT令牌过期，我们的应用程序也必须100%可供用户使用。(有些紧急情况)。用户/应用程序无法等待重新登录并获得新的JWT代码。。
问题：在不从后端获取新令牌的情况下，长时间(…永远)保护API调用的最佳方法是什么。当每个请求都用移动应用程序的共享密钥加密，每个请求都附有当前日期和时间附件时，我看到了一些时间变化。。。但我不确定它是否是一个好的解决方案，至少它会有性能问题(加密/解密请求的操作时间)。
API用户JWT TOKENS
通常我们通过JWT(访问和刷新令牌)保护移动API。用户/应用程序无法等待重新登录并获得新的JWT代码。。
这只允许您的API服务器知道谁在请求中，而不允许什么正在执行请求。
访问API服务器的世界卫生组织和什么不同
我写了一系列关于API和移动安全的文章，在文章中，为什么你的移动应用程序需要API密钥？您可以详细阅读谁和什么正在访问您的API服务器之间的区别，但我将从中提取要点：
what是向API服务器发出请求的东西。它真的是你的移动应用程序的真实实例，还是机器人程序、自动脚本或攻击者用Postman这样的工具手动在你的API服务器上戳来戳去？
谁是移动应用程序的用户，我们可以通过多种方式对其进行身份验证、授权和识别，例如使用OpenID Connect或OAUTH2流。
因此，请考虑谁作为用户，您的API服务器将能够对数据进行身份验证和授权访问，并考虑What是代表用户发出请求的软件。
你的问题
但我们刚刚面临的情况是，即使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时最佳实践的文档门户。
您需要做的第一件事是风险评估，基本上是：
- 你完全信任什么
- 你可以信任的东西
- 你不能信任的
在第一类中，当身份验证令牌来自第三方或由用户输入时，您可能具有身份验证令牌。
在第二种情况下，你可能有一些东西可以识别你的移动设备，但第三方不容易知道(例如设备的出厂ID或传入的IP)
在第三个例子中，你会有设备发送的信息，比如"这是正在连接的用户">
根据这一分析，您最终会得到一些解决方案。举一个虚构的例子：
- 通过多因素身份验证识别呼叫者时对数据的完全访问
- 从已知IP连接时信息有限
- 使用正确的JSON模式访问时的公共信息
- 拒绝无法理解的请求
没有奇迹，在某种程度上，你需要信任某些东西——这取决于攻击者多么容易获得或修改这些信息。