Its a more complicated spec in both detail and how signatures are created. The fact that the URI or body includes both resource parameters and token/signature parameters makes it necessary to parse and sort the parameters, deal with encoding, etc. If we limit signed request to the header, then all the protocol parameters are separate from the API request and we can sign it with little normalization by treating the request URI and form-encoded-body (typically a short single string) as opaque strings.
Supporting URI query and form-body for bearer token means adding a single (simple) parameter to the request: oauth_token=something. Adding the signature parameters mean at least 5 (token, signature, timestamp, nonce, algorithm). You can always extend the protocol. Moving this feature elsewhere is a worthy optimization to make signatures (and the overall spec) easier to understand. EHL On 4/9/10 6:34 PM, "Jonathan Moore" <[email protected]> wrote: However, this doesn't address my earlier use case of a signed, cross-domain JSONP call, especially if it's sitting on a non-HTTPS page; I need to make a non-HTTP XHR request to obtain a (signed or tokenized) URL to include in my <script> include, so requiring a bearer token and SSL basically forces me to have the whole page delivered over HTTPS, which may be overkill for my application. While I can understand that token and secret acquisition might need SSL, always requiring it on authorized requests too seems too much. Can someone explain/re-explain why query parameter signatures need to be eliminated? The Authorization header is great when you can manipulate it, but you can't always. Why is it problematic for the signatures to be able to appear in either place? Jon ........ Jon Moore On Apr 9, 2010, at 1:39 PM, "Eran Hammer-Lahav" <[email protected]> wrote: In practice this is the same as logging in which I expect to require SSL anyway. Signed or not, attackers should not be able to login to your email account simply by using a MITM attack when you click on your IM client. So SSL is required already. EHL On 4/9/10 7:30 AM, "George Fletcher" <[email protected] <mailto:[email protected]> > wrote: Yes, this is possible, though to be secure it should really happen over SSL which is less of a requirement for a signed request. I guess the main question is whether we really need to remove the signature related parameters from URL and only allow them in the Authorization header. For signed requests, these use cases pretty much require that the signature parameters be allowed in the URL. Obviously, if we change our model to not use signed URLs then this issue goes away:) Thanks, George On 4/9/10 12:58 AM, Brian Eaton wrote: On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]> > wrote: I realize that these sorts of use cases are trivial if establishment of the SSO session switches from a signed mechanism to the OAuth WRAP bearer token model. The one nice feature of the signed URL is that it is one time use where the bearer token can be replayed multiple times. Yep, Google does this kind of thing too. Is there something that stops you from declaring that a particular token is single use? 1) Client makes call to Authorization server, passing in either the refresh token or an access token (depending on the security model you want.) 2) AS returns a token. 3) Client uses the token to pop open a web browser. Cheers, Brian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
