Secure data exchange between mobile application and backend?

Question

OAuth

1) How does the mobile application usually communicate with the backend to avoid request emulation?
2) If you send sha256(request_data+salt) along with the request, i.e. hash from request_data+salt, and check on the backend, is this a good solution?
The hash is naturally also sent to the backend.
It is necessary to reduce the possibility of forgery of the request as much as possible.
The data does not need to be encrypted.
There is no authorization in the application.

Answer 1

NO WAY. Anything on the client can be broken. The protocols of interaction between the client and the server will be opened and the call will still fly to the server, there's nothing to be done.
1) You can protect yourself from schoolchildren and hackers using SSL / TLS. If you have a REST API, then you simply put a certificate on the server using Lets Encrypt or a third-party provider like CloudFlare.
2) In REST, data is passed by URL. The first thing the person who decompiled your application will do is look for the URL in the code. Encrypt the URL in some base64 or some other way. The code itself will need to be obfuscated, confused.
3) Make life as difficult as possible for hackers. For example, limit the number of requests per minute or per hour. Issue sometimes captcha, complicate the authentication protocol (for example, change the key often and in different ways, divide the keys into parts and get them using different methods). With obfuscated code, this will be quite difficult to track down.
All this can be bypassed by an experienced person in 5-10 minutes. The intermediary between the client and the server simply rises and a fake certificate is stupidly placed or the keys are substituted. Thus, an attacker can "debug" your interaction protocol.
All protection measures are aimed at complicating hacking, and not its impossibility.

Answer 2

1) use ssl so that traffic cannot be sniffed
2) but if I'm not mistaken, even with ssl you can somehow find out exactly what data is sent to the server, and you can send your requests. Nothing much can be done about it, the maximum is to limit the number of requests for one client

Answer 3

Already there was a correct answer - in any way. From a technical standpoint, the client will not do mutual authentication with the server. Yes, they will raise the proxy and analyze the protocol.
I can offer a different solution to the issue: if you need to get rid of the "unofficial" clients of your service, then by controlling both the "official" clients and the server, you can synchronously roll out updates that change the interaction protocol in some way that will require a second protocol reverse. It is clear that the reverse will be done - but this is trouble, work and time. At this time, unofficial clients will "fall off" from the server - which will encourage users of these clients to switch to a working official application.
The number of updates of the client-server interaction protocol is not limited. You can have fun every week by completely changing the URL scheme of the server - let the authors of the non-original application run after the locomotive. There is a high probability that they will get tired. Or their customers will get tired))