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.
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.
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.
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.