On Wed, Jan 13, 2010 at 9:51 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Authentication Open Question #2: Should the normalized request be included > with the request? > > In OAuth 1.0 the request is normalized into the signature base string by > the > client and the server. The base string itself is never sent with the > request. Brian Eaton proposed [1] to include the signed string with the > request, removing the need for the server to regenerate the normalized > string, as well as allowing the client to use the included string to send > additional (signed) information that is not part of the HTTP request. > > This is a significant departure from OAuth 1.0, but one that does call for > an in-depth discussion. > > Some advantages to this approach are: > > - the server can easily verify what is being signed > - the client can include additional parameters in the signed message > - the request remains valid even if changed by proxies or other > intermediaries > This is the part I didn't get in Brian's original thread, either. Presumably, a request is valid only if the pieces in the normalized part and in the raw part somehow match. If an (untrusted) proxy changes the raw pieces, it destroys the request just like it would in normal OAuth, right? I don't buy that we need to move heaven and earth just because some people don't know how to put a signature base string together. If we believe that the "meddling proxy" use cases are important to support (i.e, we believe that a request modified by a third party should still carry the same authority as the unmodified request), then we should just drop signatures altogether and use bearer tokens. I don't see how getting rid of the signature base string helps. Dirk. Some disadvantages are: > > - the request is sent twice, once raw and once normalized > - it adds another place to make mistakes and create security holes if the > server uses the raw data without fully comparing it to the normalized > (signed) data > - since any server enforcing security will only use the data contained in > the normalized portion, it will create a de-facto standard for API requests > (not nearly as heavy as SOAP or WS-*) in which case the request itself is > normalized before sending. > > QUESTIONS: How do people feel about this? What are some other advantaged > and > disadvantages of this approach? > > > EHL > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
