Mobile-to-Server API Security

Question

I am tasked with designing a system that will allow our users to also sign in to their accounts and interact with our service using their mobile phones. I am concerned about the security of the application though.

Basically, we allow people to login via OAuth using Facebook or Twitter. The mobile application (built with Appcelerator titanium) should do that too. Upon a successful login on the phone, I need to notify my app that someone logged in with FB or Twitter so that my app can retrieve user's app-specific user id.

My first thought was to write an API that the phone could call out to which would accept parameters such as the Facebook or twitter userId. I would query my database and find their internal user id and return it to the phone.

This would work fine, but its completely insecure. Anyone could hit that same API with a Facebook user id and the API would just return the internal ID (and any other data needed by the app) without knowing if the request is authorized.

This is my first mobile app, so I am a little unsure of the correct way to implement security on my API.

Secrete

How did you worked around with it? I have exactly similar use case – Campstool

Answer 1

Most API setups include some type of secretKey or APIKey that is unique to the developer. Since you are the only developer you could just set a key/hash in your mobile app that is passed through also for a successful return of data.

http://lcsd05.cs.tamu.edu/slides/keynote.pdf is a keynote given by Google about designing a good API from the ground up.

Also check out this previous question

Legacy

Thanks but this doesnt help much, and the issue isnt about good API design. My concern is that there is no way to know who is submitting a request to my API. The phone will hit the API with some request parameters but a hacker could just as easily construct a similar request by hand. How could I prevent that? – Secrete

A secret key only works when you dont distribute it. I cannot put a secret key on a client side device because anyone can decompile the app or sniff the traffic to expose the secret key. Then it is no longer a secret. – Secrete

@bh88: any information that the app needs to submit to the server can be decompiled, so whatever the app can do, can be copied – Eger

We've just run into same thing. Have you found any solution of the issues presented in these comments – Ninefold

running into this as well. secret key can be decompiled. why was this answer accepted? – Hachure

Answer 2

1. If you can , use https, and lots of problems solved.
2. when successfully login, you can create a session and pass sessionid to client, here I advice you to send the sessionid with RSA way( for the case that someone can sniffer your sessionid)
3. use hash signature to make sure the request is not modified on the way, but this method can not prevent repost issue.

Finally, for your problem, if there is new progress, please let me know, thanks!

Conception

Answer 3

I've faced this issue too, authenticating the user is straightforward enough but authenticating the device is much harder. Like you said, anyone can connect to your API and present a user authenticated via Facebook and access your API.

You can handle it with mutual SSL authentication but then if the key is compromised on any single mobile device the entire API is compromised since all devices would be using the same key pair that came with the app when it was installed.

What I finally did was force the device to register itself with my API when the app is first installed. The device makes an API call out to my server and is issued an API key secret it then has to use to make all other API calls. This isn't secure in that you could write a script to register itself and get an API key but it does allow me to monitor API usuage and turn off devices that are behaving badly.

That's the best thing I could come up with, a way to lock out unauthorized devices that I identified out of band.

Ethelethelbert

Answer 4

I had the same issue and I solved it by creating my own API(PHP) in combination with a proxy server(NodeJS). Every request from my client is being send to the proxy server, the proxy server validates the request and passes it to my API. The API only allows requests from the proxy server his IP.

First the user authenticates with the proxy server by using the Authorization header, if success the user will get 2 tokens. An access token and a refresh token. The access token is used to make requests and lives for 5 minutes in my case. When the access token is expired the user can refresh the token with the refresh token which lives forever.

Create a global module in your app which handles your key logic, store your keys in your local properties and use them when the user restarts the app so that they don't have to relog every single time.

If you use this with HTTPS the keys can't be sniffed and you can't retrieve the keys if you decompile app because they're stored on the users device and not 'hardcoded' in the app itself. Technically if the attacker has the user's device he is able to decompile the app and retrieve the keys. I know this but if he already has access the the physical device he would be able to use any app anyway.

The proxy server also logs every incoming request and notifies me by email when someone is trying tricks(I created this myself). I used the following modules:

• express
• https
• http-proxy(proxies the request to my API)
• jsonwebtoken(generates and validates access/refresh tokens)

Drear