How to protect Rest API from being used by third parties?

Question

Mobile development

Friends,
there is a Rest API that is used in iOS and Android mobile applications.
This API works without user authorization.
The challenge is to protect the API from being used outside of the mobile app. So that no one takes data directly from the API.
What are the options?
Generate an OTP code on the server and in the mobile application and sign all API requests with it in the mobile application?
I understand that it is impossible to 100% protect the API from being used outside applications, my task is to slightly complicate this process so that with the help of a sniffer (charles) they cannot find out the addresses and use them.

Answer 1

Let's look at the question a little more structured.
Unauthorized use by an unofficial client means we are trying to protect the client.
Https with an API key will only protect against trivial traffic interception by a sniffer (mitm).
If they open the application and get an identification key for signing requests, there will be a problem. Here we already include protection against "picking". IMHO, the best option is a planned release of an application update with a key replacement, and, possibly, making certain changes to the storage of this key (so that hacking the client requires a certain time). When the people get tired of breaking.
If you are not tired of breaking, then you should think about the reasons: why does someone really want to have an unofficial client for your api. It will be easier to agree here - or continue to play swords and shields.

Answer 2

The problem is most likely not in what the left people will use, but in abuse, but the same can be done directly from your program, so the best solution is to make a public api but introduce quantitative and frequency restrictions.

Answer 3

https+app_key

Answer 4

Everything is described in detail here .

This API works without user authorization.

As a "transparent" (for the user) authorization of the application (on the server API), on the client, we use two parameters to generate the requesting authorization token: information identifying the device and the public server key.
Token: We encrypt the device ID (or any identifying information of the mobile device) with the server's public/public key stored in the application.
On the API server - we log all authorization errors.
When they appear, we release a new client with a new open / public server key and a new token generation logic.

Answer 5

In short, no way, because. any protection can be bypassed, and it is very easy to reverse an android application.
And so, they often use request signing, ideally, the signing algorithm should be written in a compiled language like C ++. You also need to add a timestamp to the request so that you can’t just send requests by stupidly copying the package with a sniffer. You can also obfuscate the API, making it slightly more difficult to use. But whatever you do, you can bypass it all.

Answer 6

I suggest using Google Cloud Messaging (GCM).
The device registers with GCM, receives a registrationId - a token - stores it locally and passes it to your server. The push server then uses this registrationId to send messages to your app on that device. In the message, pass the string generated on the server. The application must return this string to the server. And only after the strings match, you allow access to the API for this device.
Thus, only your application will have access to the API. Even if someone unpicks the application, or creates a clone of it, it will not pass validation and will not be able to receive your pushes. Neither change the API, nor encrypt requests/responses, nor switch to https, etc. you don't need this solution.

Answer 7

https://jwt.io/