1

I'm developing an android app and I want to restrict access to my API to my website and mobile application. I'm not interested in having the user login into my app, rather, registering the client.

I've refrenced these resources for this task:

Here is what I did thus far:

  1. Generated an android and web client api key from the google cloud console. It looks something like this: ALzfShCF_mD_IVlVVVf2783TG9FG8x7u0s-ZFQE (not real key)
  2. Made a constants class, added these to my API declaration for clientIds

    clientId{android_key,web_key} && audience{web_key,android_audiance}

  3. Added a User user param to each method

  4. Rebuilt project, deployed.

All of these resources seemed helpful, especially the documentation. However, I didn't notice any difference. I expected to see, after I followed the documentation and redeploy my backend, both my website and app fail to call my endpoint functions. However, they both worked flawlessly.

Would following these posts or documentation prove my case, or is there something else I must do? I also dont want unauthorized access to my API explorer as well!

Any help would be greatly appreciated!

Edit:

I'm using the wrong keys, I was using the API key instead of the CLIENT Id. Once I updated that I saw that my API requests are failing because the user param is null. Now my question is, how can I not pass a non-null user object without getting the user to login?

I tried making a GoogleAccountCredintal and passing it to my ApiBuilder in my Async task, but its always null.

GoogleAccountCredential credential = GoogleAccountCredential.usingAudience(context,APIClientKeys.ANDROID_CLIENT_ID);

MyApi.Builder builder = new MyApi.Builder(AndroidHttp.newCompatibleTransport(),
                    new AndroidJsonFactory(), credential) ...
Community
  • 1
  • 1

2 Answers2

4

A very wise web developer once said

"Never Trust the Client".

No matter how sophisticated mechanism you come up with to secure your application, all it takes is a Network Inspector (Like one you can find in your web-browser) and a code inspector (which you can also find in your web-browser). Now some might suggest to obtrucify your client (that is mangling code enough that someone can not just see it). However, if someone really wants to de-obtrucify your application. With significant effort they will and once they have successfully reverse engineered your client, they can write their own malicious client to abuse your endpoints.

So what can you realistically do?

  • Rate limit usage on some endpoint using some rate-limiting technology (like Limitd) by an IP or other parameters and then start blacklisting IPs if they abuse your service this will make it really hard to abuse your apis.
  • Force users to login.
ShrekOverflow
  • 6,795
  • 3
  • 37
  • 48
-2

How about this: Setup a secret key on your server and your app. Let’s say it’s SECRETKEY123. When making a request to your API, send an extra parameter called auth. In it pass the md5 (or any other, say bcrypt) hash of your parameters and the secret key. (Note: The secret key should not be posted)

So something like auth = md5(param1 + param2 + SECRETKEY123);

Then on your server perform the same hash using the secret key already stored on the server. Compare the two hashes – I.e the one you submitted and the one you generatd on the server. If they match allow access – otherwise restrict access.

  • This method is called HMAC. I have tried to describe as simply as I could. The most standard way would be to use oAuth I suppose - but I find this method easier and elegant. You can read more about HMAC here: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf – Hamza Javed Jun 10 '16 at 19:30
  • Thank you, I'll give this a try. – Charles Hennessey Jun 10 '16 at 20:20
  • 1
    That won't work, it is rather simple for anyone to decode this in your application and fetch this hash and do the same thing. – ShrekOverflow Nov 20 '16 at 13:20
  • it's possible to just find the value of secretkey123 on the client side, it's so simple and insecure that you may as well omit it altogether – bitten Nov 20 '16 at 13:51