How do people handle authentication for RESTful api's (technology agnostic)

Question

i'm looking at building some mobile applications. Therefore, these apps will 'talk' to my server via JSON and via REST (eg. put, post, etc).

If I want to make sure a client phone app is trying to do something that requires some 'permission', how to people handle this?

For example:

Our website sells things -> tv's, car's, dresses, etc. The api will allow people to browse the shop and purchase items. To buy, you need to be 'logged in'. I need to make sure that the person who is using their mobile phone, is really them.

How can this be done?

I've had a look at how twitter does it with their OAuth .. and it looks like they have a number of values in a REQUEST HEADER? If so (and I sorta like this approach), is it possible that I can use another 3rd party as the website to store the username / password (eg. twitter or Facebook are the OAuth providers) .. and all I do is somehow retrieve the custom header data .. and make sure it exists in my db .. else .. get them to authenticate with their OAuth provider?

Or is there another way?

PS. I really don't like the idea of having an API key - I feel that it can be too easily handed to another person, to use (which we can't take the risk).

Solution 1

Our website sells things -> tv's, car's, dresses, etc. The api will allow people to browse the shop and purchase items. To buy, you need to be 'logged in'. I need to make sure that the person who is using their mobile phone, is really them.

If this really is a requirement then you need to store user identities in your system. The most popular form of identity tracking is via username and password.

I've had a look at how twitter does it with their OAuth .. and it looks like they have a number of values in a REQUEST HEADER? If so (and I sorta like this approach), is it possible that I can use another 3rd party as the website to store the username / password (eg. twitter or Facebook are the OAuth providers) .. and all I do is somehow retrieve the custom header data .. and make sure it exists in my db .. else .. get them to authenticate with their OAuth provider?

You are confusing two differing technologies here, OpenID and OAuth (don't feel bad, many people get tripped up on this). OpenID allows you to defer identify tracking and authentication to a provider, and then accept these identities in your application, as the acceptor or relying party. OAuth on the other hand allows an application (consumer) to access user data that belongs to another application or system, without compromising that other applications core security. You would stand up OAuth if you wanted third party developers to access your API on behalf of your users (which is not something you have stated you want to do).

For your stated requirements you can definitely take a look at integrating Open ID into your application. There are many libraries available for integration, but since you asked for an agnostic answer I will not list any of them.

Or is there another way?

Of course. You can store user id's in your system and use basic or digest authentication to secure your API. Basic authentication requires only one (easily computed) additional header on your requests:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

If you use either basic or digest authentication then make sure that your API endpoints are protected with SSL, as otherwise user credentials can easily be sniffed over-the-air. You could also fore go user identification and instead effectively authenticate the user at checkout via credit card information, but that's a judgement call.

Solution 2

As RESTful services uses HTTP calls, you could relay on HTTP Basic Authentication for security purposes. It's simple, direct and is already supported for the protocol; and if you wan't an additional security in transport you could use SSL. Well established products like IBM Websphere Process Server use this approach.

The other way is to build your own security framework according to your application needs. For example, if you wan't your service only to be consumed by certain devices, you'll need maybe to send an encoded token as a header over the wire to verify that the request come from an authorized source. Amazon has an interesting way to do this , you can check it here.

Comments

[David]

There are some great answers to this question at: stackoverflow.com/questions/5511589/…, and stackoverflow.com/questions/3358501/….

[mkirk]

definitely don't use HTTP basic auth without SSL, as the username and password would be sent in plain text. Read more here: security.stackexchange.com/questions/988/…

[Ryan Pelletier]

I think building your own security framework should only be used as a last resort, there are many good existing frameworks which have been tried and tested.