Unfortunately I will say, regardless of the solution what you want is not possible, at one point or another the same can be broken, simulated or emulated.
Asymmetric or symmetric key does not change this.
All these techniques will only hinder but never inhibit the actions of someone with knowledge and interest.
In these cases you should work with the kind of security that is worth it. Do not put something too complex because you need to maintain, or put something too sophisticated, because maybe a simple key will never be seen. It all depends on the type of application and the interest of those who know.
Giving only one line to guide yourself, see how to obscure your code. Using Java merge with C also helps.
Obscurcer can also be used at the API level, but in these cases you use something like Swagger to define the API, and then some other solution depending on the language to shuffle the requests.
Use SSL on endpoint makes the break difficult, if used together as GRPC already increases the level of complexity with performance gains but with increased spending on infrastructure.
One solution is to use a key in each version of APK. Whenever a new version leaves you disable the access of 1 or 2 previous versions, if you join this with the GRPC, and perhaps with the generation of 'login' per installed application, each keeping a registered key, or even a login where you return a key to be used (asymmetrical) where you can selectively cancel as you wish.
From the server’s point of view, he has no way of knowing for sure what kind of application made the HTTP request. You can identify the client program in most cases by the property
user-agent
of the requisition, but it’s manipulable, and any 12-year-old boy who’s vacated knows how to do that. Don’t lose sleep because of this requirement of not being able to access the API from browser as it is a lost fight ;)– Oralista de Sistemas
@Raphaelcastro on the one hand is a public API but then does not want public. Maybe the concept is a little confused. If your app has public distribution which means it can be executed at any point... So your API really has to manage those requests that come from anywhere. You need to think like this....
– chambelix
That’s what I was thinking, it’s probably better to strengthen the server-side application than to keep breaking your head with the client-side.
– Rafael Alexandre
@Raphaelcastro That’s right. It is the server that has to dictate the rules and with the definitions the API appears naturally. However remember that developing a root authentication system is no easy task.
– chambelix
Unfortunately I will say, regardless of the solution what you want is not possible, at one point or another the same can be broken, simulated or emulated. Asymmetrical or symmetrical key doesn’t change that. All these techniques will only hinder, never inhibit the actions of someone with knowledge and interest. In these cases you should work with the kind of security that is worth it. Do not put something too complex because you need to maintain, or put something too sophisticated, because maybe a simple key will never be seen. It all depends on the type of application and the interest of those who are aware.
– Gregorio bonfante
HTTPS is a must-have so that your api is not intercepted. Search for the implementation of the Oauth2.0 protocol, in case for android applications you will need to implement client_credential. You can also prevent a "Trust", a hash based on something unique within the application (checksum would be possible?) to ensure that the request is actually coming from your application.
– LeonanCarvalho
PHP has functions to impel a hash-based authentication, take a look https://en.wikipedia.org/wiki/Hash-based_message_authentication_code And also look at this question, have insights relevant to your problem : https://security.stackexchange.com/questions/18572/is-it-okay-for-api-secret-to-be-stored-in-plain-text-or-decrypt-able
– LeonanCarvalho