Getting started with designing a Secure REST (Web) API
thebuzzmedia.com
Getting started with designing a Secure REST (Web) API
1–10 of 17 posts
Re: Getting started with designing a Secure REST (Web) API
#2What's wrong with an approach of:
- For client access to a server, use basic auth over HTTPS
- For client/server to server access, use OAuth
Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far.
[Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check out how it would work].
Re: Getting started with designing a Secure REST (Web) API
#3I didn't read this for one simple reason - the dismissal of OAuth as complex. It's not that bad and it is secure. It's proven secure by experts and open source libraries exist.
Re: Getting started with designing a Secure REST (Web) API
#4What's wrong with an approach of: - For client access to a server, use basic auth over HTTPS - For client/server to server access, use OAuth Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far. [Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check…
Using OAuth 2.0, there's no reason to differentiate client and other server access like that.
Re: Getting started with designing a Secure REST (Web) API
#5I didn't read this for one simple reason - the dismissal of OAuth as complex. It's not that bad and it is secure. It's proven secure by experts and open source libraries exist.
His solution turns out to be close to OAuth 2.0 in the end, so you are right. But I liked the article because it walks you through the thought process of someone trying to do it on their own. This understanding of all the small things you may end up ignoring in your own efforts actually makes a stronger case for OAuth then believing an expert's words.
Re: Getting started with designing a Secure REST (Web) API
#6I didn't read this for one simple reason - the dismissal of OAuth as complex. It's not that bad and it is secure. It's proven secure by experts and open source libraries exist.
His solution turns out to be close to OAuth 2.0 in the end, so you are right. But I liked the article because it walks you through the thought process of someone trying to do it on their own. This understanding of all the small things you may end up ignoring in your own efforts actually makes a stronger case for OAuth then believing an expert's words.
Actually, it was basically 2-Legged OAuth 1. I was shaking my head all the way through the article, having gone through the same process about a year and a half ago.
We (developers) do love re-inventing wheels.
Re: Getting started with designing a Secure REST (Web) API
#7What's wrong with an approach of: - For client access to a server, use basic auth over HTTPS - For client/server to server access, use OAuth Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far. [Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check…
It provides an additional layer of security over HTTPS/BasicAuth, so if your SSL certificate or even the CA is compromised, you retain a degree of security.
On the other hand, it makes it more difficult for developers to access your API; you can't just send requests over Curl, for instance.
Re: Getting started with designing a Secure REST (Web) API
#8You realize that hashing the password and sending the hash over the wire in lieu of the plain-text password still gives people sniffing at least the username for the account and a hash of the password that could (in a disturbing number of cases) be looked up in a Rainbow Table.
No. Getting the username and cracking the hash is the least of your concerns. The problem of just hashing the password and sending it over an unsecured channel is that you're vulnerable to replay attacks: the attacker doesn't need to crack it, just re-send the hash. Essentially, the hash becomes a plain-text password.
Re: Getting started with designing a Secure REST (Web) API
#9What's wrong with an approach of: - For client access to a server, use basic auth over HTTPS - For client/server to server access, use OAuth Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far. [Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check…
It provides an additional layer of security over HTTPS/BasicAuth, so if your SSL certificate or even the CA is compromised, you retain a degree of security. On the other hand, it makes it more difficult for developers to access your API; you can't just send requests over Curl, for instance.
Good point about curl - a strong motivation of mine was to make the API easy to access through tools like curl.
[I have seen some discussions about adding explicit support for OAuth in curl]
Re: Getting started with designing a Secure REST (Web) API
#10When it comes to security please do not try to hack together your own thing it rarely ends up well.
People still think OAuth is complicated. OAuth 1 was very complicated and caused untold issues for implementers who didn't use libraries and for those of us who maintained libraries who to this day tell us that our proven libraries implement things wrong.
OAuth 1.0 should not be used for any new applications. OAuth is dead long live OAuth(2).
OAuth 2 is essentially ready to be used, but unless you need to deal with token issuance and delegated access you don't even need that.
If all you need is an API token over SSL then use the Bearer Token spec is what most people call OAuth 2 and is just a single token in a http header or query string. It is incredibly easy to implement and you don't even need a library.
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16
More complex but if for some reason you don't want to use SSL or if you need to share url's similar to Amazons signed urls where you need to give some access to a resource such as an image or download use the Mac token, which is receiving serious security analysis now:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-0...
Both of them are still officially drafts, but are mainly receiving wording changes now. I'd say they are both ready for primetime.