

Designing a Secure REST API Without OAuth - rkalla
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

======
rkalla
Would appreciate any feedback on the article from any HN'ers that have done
large-scale web APIs and run into any gotchas with different approaches.

For example, is the format used to glob the param/value pairs together
(besides using name=value) critically important as long as they are delimited
appropriately? (avoiding AWS sig v1 issue).

Or is the order of applying the private key and HMAC important? In the AWS
example it looks like you prime the HMAC-sha1 instance with the private key,
then sign the data... would that be the same as just appending the private
key, the data, and the timestamp all together and signing that?

Also, what do you think of the real-world implications of using the timestamp
and an acceptable range on the server side to avoid "replay attacks" as a
means of making an API a bit more secure? AWS doesn't use it... I was
concerned with clients/servers being too far out of sync in some cases where
the client may not be able to adjust it's system time easily OR an incorrect
DST calculation between the two making the server think the client is suddenly
1hr more than it should be (namely at the switchover boundaries)

Just a few thoughts that came to mind that I'd be curious to get feedback on
from folks smarter than me.

------
turtle4
This was helpful. I've looked at AWS before briefly, but this helped me
understand the process better.

This seems like a good set up for server to server API requests. One question
I still have is how to most safely query such an api from a client, rather
than another server. ie, if my web app clients need to pull data from the rest
api, is the only option to have them go through my web app server as a proxy,
rather than pull the data from the rest api directly? I don't see a way around
that.

~~~
rkalla
turtle, I'm glad it helped... the whole subject had me confused until I looked
into it more.

If you need a client to communicate with the API, the client will need the
private API key to encrypt the payload and then it can talk with the API
directly.

In AWS terms, this is the "Secret Key" that is hidden by default under your
Account Access Security page.

If you are trying to publish a public API though, for use by anyone and not
"developers", you probably want to go with an OAuth approach.

If you are controlling who has access by way of an API key though, going the
route outlined in the article should be fine as every account would get a
public/private key assigned to them.

