Duplicating request component in an HTTP authentication scheme

The OAuth working group is debating how to make signed authenticated requests. The two main questions is what do sign, and what to sign it with. On the 'what to sign part' we know we want to sign the request URI, HTTP method, and host name (among other cryptographic attributes such as timestamp and nonce).

OAuth 1.0 includes a normalization process taking the request and serializing it into a base string (which is then signed). For OAuth 2.0, we have two competing proposals:

1. Normalize the request and send just the signature
2. Normalize the request and send both the signature and the signed string

The advantage of #2 is that is moves the complexity from the client to the server. It is up to the server to figure out if the signed blob matches the request itself. The issue is that by doing so, the HTTP request is duplicated (HTTP request and authentication blob). Server will be required to compare the request with the blob to make sure they match. In practice, servers can ignore the request and just respond to the blob because it's the authenticated copy.

The ramification of #2 is that it moves the HTTP request bits to another layer, creating a sort of wrapper.

However, this approach should make it easier for client developers (who proved themselves to be extremely incompetent with the 1.0 specification) to get signatures right. It also allows for signing arbitrary data in addition to the HTTP request.

Thoughts?

EHL

Received on Thursday, 27 May 2010 23:11:57 UTC