To clarify a bit in terms of of the flexibility I mention being gained by keeping a body hash filed in the headers and for constructing the signature - I'm imagining myself implementing 2 layers of servers for handling the upload and processing of large files.
The public facing server (e.g. a load balancer and auth server where SSL terminates) could hold all the secrets and verify the signature based on just the headers including the body hash. Then, a back-end sever could take the request body and verify the body hash (returning a 403 if it doesn't match) without needing to have access to the client secrets. I agree with your comments at http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ that the core spec should be based on HMAC signatures. I was previously very disappointed when looking at the main Oauth2 spec and seeing only the bearer token approach or the approach of sending the secret in the request. Seems like barely an improvement over http basic auth. Perhaps a bearer token is suitable for use cases of just reading public or semi-public data, but even then I'm astounded that the operation of getting a refreshed token would not use an HMAC based signature instead of sending the secret. Best, -Peter Wolanin On Sun, Feb 27, 2011 at 9:59 AM, Peter Wolanin <[email protected]> wrote: > Dear Mr. Hammer-Lahav > > regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > > I was quite happy to find this, since I had overlooked it before and > it define the sort of robust HMAC-based auth we have been using for > our APIs in various forms, but has the advantage of being a standard > that if implemented would make our future implementations much more > standardized. > > I was a little unclear in the spec whether the client can choose not > to include the body hash in the signature. I'd hope that the spec > ends up clearly requiring the client to always send it even if a given > server may or may not validate the body hash. Our current > implementations include the body directly in the HMAC calculation, but > considering your current draft I appreciate the extra flexibility > provided by signing over the body hash rather than the body itself. > > A downside to the MAC spec for OAuth2 is, as far as I can see, you > have to send your client secret in the request if you ever need to > refresh your OAuth token? I see in some recent messages liek > http://www.ietf.org/mail-archive/web/oauth/current/msg05214.html some > discussion that suggests I'm mistaken? > > Also, as stated in section 7.3, there seems to be no provision for > ensuring response authenticity except relying on SSL. We have been > using protocols that include in the response an HMAC of the response > body calculated to include the client-supplied nonce. Obviously one > could add such a response header without breaking the protocol, but > I'd like to see an option in the MAC credentials an added field that > specifies whether the server is expected to provide such a response > HMAC and a standardized name and construction for such a response > header. > > -Peter > > -- > Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. > [email protected] : 978-296-5247 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; > -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. [email protected] : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
