How to uniquely identify your Android app for rest

Question

Is there a way to uniquely identify my Android App in Java code? Maybe some combination of the package name and something else? I know there is a way to identify a unique Android device, but that is not what I am looking for.

I want to be able to uniquely identify my Android app that I made so that I can then pass that information to my own private RESTful API. This would allow me to verify that the call is coming from my Android App and not another unauthorized one. I want my RESTful API to only work with the app I made and so no one can spoof it or access it unauthorized.

Or is this an impossibility? I'm just wondering how apps like Snapchat have their own login and what not. Clearly something there is securing it.

Answer 1

If you want to use google maps from inside your app you need to supply an API key with every request. Google Maps Android Developer Site As far as I know that is the same mechanism that they also use to identify your app for advertisements. This key is transmitted in clear text so it can be intercepted. They do fraud detection to prevent misuse, so if your RESTful service is of the same kind as maps or ads this is the way to go for android apps.

If you have high value data like snapchat (nudes from people) the users have to provide a secret aka password to secure the connection. If you want to keep the effort for the user low you can use facebooks or googles authentication mechanisms.

Also take a look at Rest Security Cheat sheet it will give you a nice overview of the topic. (Especially the Authorization section.)

Answer 2

This is a pretty broad topic area that's more related to the actual design of the RESTful service than Android. Generally speaking, RESTful services should be designed with the idea that anyone can access them, and you create security to ensure that your users data is kept private and only accessible by people who have the authority to access it as the reality of the internet is that once the endpoint is out there, people can and will try to access it.

Personally, I usually end up using JSON Web Tokens (JWT). You can include in a header a token that is validated by the server using credentials the user provides. This allows you to validate credentials and reject unauthorised access, as it is based on OAuth, as well as contain some additional ways to secure the service, including token expiry, so that the application has to renew the token every X minutes/hours/days etc., in case someone malicious does get a hold of the token. This also provides you a simple mechanism to identify the current user straight off the token. Here's a good introduction to JWTs and what they are composed of.

In summary, the nature of web services is that once they are exposed, any web connected device can theoretically connect through spoofing, packet inspection etc., and the only way to counteract it to block it to only your app connecting is to authenticate at a device level, which would require knowing every single device that is going to connect to the service. What I believe you need instead is strong authentication at the service level. A good REST API is platform agnostic, and used between apps and websites alike, with priority being on the security at a request level, rather than at a device level.

Answer 3

As others have mentioned, sending a static identifier is not going to ensure you are only picking up access from your app.

You need a way to create a handshake between your API and app, a simple but quite secure way of doing this is to have a key that both your app and your API share. When you make an initial connection to the API you create a random string, encrypt it using the shared key and pass the string and the encrypted string to the API, the API then encrypts your random string with it's shared key and compares it to your encrypted string.

For example:

Random String (RS) (generated by the app) = ABCDEFGHIJKLMNOP
Your shared key (SK) = AAAABBBBCCCCDDDD
Encrypt RS with SK to produce....
Your Encrypted string (ES) = WWWWXXXXYYYYZZZZ

send RS and ES to your API which then performs the same encryption using the same shared key. If the Encrypted strings do not match the API rejects the request and logs the RS so it cannot be used again If it does match, the RS is still logged, but access to the API is accepted. You can force re-authentication every time the app is used, you can also just send the RS with any further API requests as authentication has been completed successfully, but you must make sure that you time out the RS after a short time.

Answer 4

You may want to check one-time password mechanism. When your application installs, you authenticate your user and give a seed to your application. Whenever your application calls your Rest Service, you provide, along with service arguments, also a one-time password created from this seed.

One time password benefits.

The most important advantage that is addressed by OTPs is that, in contrast to static passwords, they are not vulnerable to replay attacks. This means that a potential intruder who manages to record an OTP that was already used to log into a service or to conduct a transaction will not be able to abuse it, since it will no longer be valid.

There exists an open standard HMAC-based One-time Password Algorithm with provided java code for you to start from.