iphone - How can I design a secure API/Authentication for mobile apps to access a service?

Question

I want to offer some functions of my webapp to be used in other apps (I'm thinking mainly about smartphones, since they offer more capabilities e.g. GPS, Camera,..).

From what I have encountered myself so far in terms of other APIs e.g. GoogleMaps, is that a 3rd party developer would register himself at my site, he gets an API key (some random UUID) and he has to use it to authenticate his requests against my website. So far so good...

Is there a mechanism to protect the end user of a mobile app from malicious apps? E.g. a 3rd party developer could build an app and capture all username/passwords from the end user, so that he can do bad stuff with the useraccount. (E.g. I could build a twitter app, capture all the usernames/passwords and then delete all their tweets, post new ones,..) Is there a possibility to prevent this? AFAIK you could use oauth on the web so that my website login box would appear on another site and ask them for their username/password, so that it isn't shown to the 3rd party site. Is it possible to implement a secure authentication for smartphone apps? How would you do it?

Answer 1

For Android and iPhone you can use OAuth without problems, and so far I think this is the best way to be done.

The flow for these two smartphone types is the same like in web applications, because both OS give you the possibility to start web browser from your application and redirect the user to web provider, so he can authorize your request (token), and then the browser can return your user to the application via proper callback URI. I haven't implemented oauth for mobile phones, but I've heard from a friend that it's possible and that the mobile browser can redirect the user back to your app with some special URI, like scheme://app/parameters.

Here is something for this with android: link

There are two oauth use cases: 2-legged and 3-legged

2-legged is when you want to protect your API, so that it can be called only from authenticated consumer applications. This is a popular scheme that exists from ages AFAIK - the consumer signs every request with a consumer shared key, and the provider (your API), signs the request also to see if the signature match. This way you can tell if API usage is ok for that consumer.

3-legged oauth includes the end-user of the consumer 3rd party app. It is very suitable, if you want to protect your API again like in 2-legged, because requests are still signed, but also your API can be protected by the end-user's permission. The provider of the API issues a token and gives it to the consumer application (3rd party app). Then this app saves the token locally and redirects the user to Provider for authorization of the token. When the user authorizes it, the provider sends back the user to the consumer application and then consumer can make authenticated (signed) and authorized (by the user - 3rd leg) requests to your API.

The protocol is not very complicated once you read how it works, and is very flexible - you can extend it to your needs however you like. I would highly recommend it for protecting APIs, especially if user permission is required for access to the APIs.

This is a very good site to read about oauth: http://hueniverse.com/oauth/

--- ADD ON ---

There is some security implications regarding shared key storage in the consumer application - mobile phone app in your case.

If somebody open your program and disassemble the code and extract the shared key, then he can make application which will authenticate successfully to the provider API. However this is not a very big concern if user authorization is required (3-legged), because the user will still be asked to give permission to this false application - and now it's up to the user to make the proper choice. And besides that - the false app will not be able to steal user's credentials, because with oauth, user credentials are entered only at the provider's site.