Search code examples
iosapi-design

Authenticating Users for an API Built for Third Party Application Developers

I'm in the early stages of developing an API for my site so that third party developers can build an iPhone application for it. The API would have a limited subset of the functionality of the full site. The trouble I have is around security and authentication for the user who downloads the application. I have come up with the following options:

  1. The user enters the same credentials they use on the site to authenticate themselves. My API would then take the credentials when accessing information specific to the user. This is my least preferred solution as the third party application could log these details and use them maliciously on the full site.
  2. Each user generates a unique key on the site which they can then use on the app to login. My API would take the API key as an argument when accessing information specific to the user. The main problem though is that any application can do what they like to the user once they gain access to their key even if the user has not given the application permission to do so.
  3. To overcome the above problem the third party developer would have to register their application with the site and then the user would need to generate a unique key per application they wish to use. This would then be used to login. This is my preferred solution as each key is unique per application and user I can tell which application called the API and whether the user approved it.
  4. My final option is to implement oAuth. We are currently waiting for the 2.0 version to be finalized and do not have the time to keep updating our code as the spec may change.

This is the first API i have had to build and I was wondering if i have understood this correctly? I'm assuming in option 1 the application could log the user credentials and use them maliciously but how does twitter overcome this issue with their third party applications? Or is it simply up to the user to trust the application they are using? If this is the case then would option 2 and/or 3 be feasible in the meantime until I switch to option 4.

I'd appreciate your feedback.

Solution

  • OAuth 1 and OAuth 2 are both viable options. But you will come a long way with basic authentication aswell (as long as it is over SSL). Don't be scared :)

    I've implemented an API provider over OAuth 1.0. And since there are so many ready made libraries for OAuth1.0 for many platforms I would not be scared of using that either, much of the work has been done already, both for you as a provider and for third party implementors.

    Anyway: you can always couple basic authentication with some very simple signing of the request using an application key and secret, say for example that as a third party developer you have to call.

    https://yourapi.com/?user=11111&password=232123&random_string=23123&api_key=THIRD_PARTY_KEY&timestamp=1212121212signature=efefefefefef

    where the API implementor has to sign perhaps the random_string, timestamp and api_key with the secret. Then you would at least have a way of shutting down malicious apps.