APIs USER JWT TOKENS
Usually we secure Mobile API via JWT (access and refresh tokens).
And users/application cannot wait for re-login and getting new JWT code..
This only allows your API server to know who is in the request, not what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between Who and What is accessing your API server, but I will extract here the main points from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the Who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the What as the software making that request in behalf of the user.
YOUR PROBLEM
But we just faced with case when our application MUST be 100% time available for users even JWT token expired. (its some emergency stuff).
You found yourself a very challenging problem to solve, but not an impossible one, and we developers love this type of challenges :).
Incoming requests
By now I hope you already understand well the difference between who and what is accessing your API server, therefore you may have already realised that you cannot trust absolutely in any request arriving to your API server. So you must treat any request as a potential attack to your API server, until proof in contrary, aka just like you are innocent in court until proof in contrary ;).
Requests Encryption
but I'm not sure that it's good solution, at least it will have performance issue (operational time to encrypt/decrypt requests).
Just like you cannot expect a free dinner when you go to the restaurant, you cannot expect to add security to any application without adding some milliseconds of time to apply it ;).
I saw few times variant when each request encrypts with shared keys to mobile app with current date-time attachment to each request...
This approach is more suitable to guarantee the data integrity in the request. By other words that it cannot be seen or modified by a Man in the Middle(MitM) attack, but will not give any guarantee to the API server that is coming indeed from what you expect, your mobile app, because an attacker can just grab the genuine request from your mobile app and replay it.
Plus an attacker can reverse engineer your mobile app with static binary analysis to extract the encryption keys, by using an approach similar to the one I demonstrate in the article
How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
If reverse engineering by static analysis doesn't do the trick then the attacker can use an instrumentation framework to hook at runtime to your mobile app and extract the keys used to encrypt the requests, therefore he will be able to generate its own request and make your API server belief that what is making the request is your mobile app, when indeed it's the attacker that has now the encryption keys.
A good example of an instrumentation framework is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Making proof that an API request can be trusted
Problem: what is the best way to secure API call for a long time (... forever), without get new tokens from back-end.
I hope that by now you have realized that by using the array of reverse engineering techniques and open source tools available, the attacker as all the time he wants to poke around your mobile app in order to understand it's hardening techniques and how to bypass them to impersonate your API server as what it genuinely expects, your mobile app. The bottom line is that you cannot secure your API server "forever" with a static solution shipped inside the mobile app.
Securing an API server is not an easy task and you should apply as many security layers you can afford and are required by law to your market.
A possible solution for your problem is to apply the Mobile App Attestation concept, and you can read more about in this answer I gave to another question, and I recommend you to pay special attention to the section Securing the API Server and A Possible Better Solution.
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I always like to reference the excellent work from the OWASP foundation, thus this answer will not be an exception :)
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
