Auth headers or parameters?

[Patrick Meenan]

Making some progress on the testing API today (thanks for everyone who
has provided feedback): http://code.google.com/p/web-testing-framework/wiki/TestingServiceAPI

I think it's time to put a stake in the ground for the authentication
scheme and in particular, where the auth information should go in the
request.

1 - As additional headers. This is how it is done with AWS and there
is good library support across languages for generating the SHA1 HMAC
signatures.

2 - As parameters in the post/request itself.

Parameters "feels" like it would be easier to implement for a lot of
users but if they are going to have to generate a signature anyway it
seems like replicating an auth scheme that is already widely used
might be a better option. Keys are going to be absolutely critical
for any public service so it's something we need to get done right up
front.

Anyone have strong feelings one way or another? I'm leaning to
replicating the AWS style of auth but I could be convinced otherwise.

For those not familiar with the actual implementation for the AWS REST
Auth, here it is: http://docs.amazonwebservices.com/AmazonS3/latest/dev/

Thanks,

-Pat

[Patrick Lightbody]

+1 to headers. By the time you're generating signatures, you're basically way past simple "curl" commands, so might as well tuck it away nicely in a header.

--
We provide FREE website monitoring and load testing
http://browsermob.com

Patrick Lightbody
BrowserMob
(w) +1 (503) 828-9003 x 101
(m) +1 (415) 830-5488

[Ian Withrow]

I don't think we should assume experienced users if we want broad adoption.  However, I'll propose the real standard for making this decision should be how easy it is for motivated newbies to acquire the necessary knowledge, not what we expect users to know know already.  So #1 is fine if we can link to or directly provide an example so interested beginners can learn.  The goal being to minimize friction for this population.

[Dritan Suljoti]

The headers approach is becoming sort of a standard for most APIs. It
is easy and flexible to implement in all dev frameworks out there. The
learning curve on this method is very low - if someone is not
experienced, it will take them 10-15 minutes to learn how to achieve.

Parameters in request URL is sort of unsafe, as quite a lot of
proxies/firewalls/etc log the request.

drit

Dritan Suljoti
Catchpoint Systems
http://twitter.com/dritans
http://linkedin.com/in/dritan

[Josh Fraser]

To be clear, I think Patrick is talking about using POST variables so the request logging / security angle wouldn't be an issue.

I'm happy with using headers and agree that the learning curve is pretty low for anyone who doesn't know to do that.  We'll want to provide lots of example code anyway for the newbs.

Josh

--
Josh Fraser

Torbit Co-founder & CEO

803.572.4626 | torbit.com | joshfraser.com | twitter.com/joshfraser

[Pat Meenan]

Well, the default signature scheme includes a timestamp which leaves a 15-minute replay window IF you manage to capture it but since the private key isn't transmitted you're limited to being able to replay the original request.  If you are concerned about proxies (or sniffed traffic) then it really should be encrypted anyway which basically leaves logging on the server side.

Right now WebPagetest uses a REAL simple key mechanism that doesn't even include signing requests.  The barrier to entry is trivial and it is basically curl-level capable (with test requests possible even over GET requests).  There is no question that we need more secure methods and the header-based HMAC schemes are well proven.  I'd also prefer not to support multiple schemes because it defeats the purpose of standardizing.  Hopefully the header-based auth is easy enough for people creating tools to implement and if we provide API wrappers for multiple languages we can hopefully lower the barrier to entry so even entry-level scripters could throw something together.

I'll go ahead and spec-out the auth based on header-based fields with the key and signature.

[Alois Reitbauer]

I am fine with header fields as well. The only thing we should define is the encoding. I just recently ran into problems with UTF-8 vs. url encoded parameters. I also would not mind about security. Like in our services we use https anyways so no the communication is secure anyways. The main point is really about authentication.

// Alois

[Sergey Chernyshev]

I agree - headers are good - after all people doing web performance analysis should understand what headers are and how to use them - it's a reasonable minimum requirement for devs using the APIs.

As for security - I believe basics should be possible to achieve without HTTPs, but replicating SSL on application layer is not a good idea so I wouldn't go crazy on the encryption properties of the protocol.

Basic protection is good enough and replay within a relatively long window (e.g. 15 minutes like Pat proposes) is reasonable drawback for non-SSL setups.

          Sergey