There are a few issues to consider. 1. Should the spec support sending bearer token in a query parameter?
- The argument that there are many use cases for this is unproven. JSON-P is one valid example (though JSON-P usage is in decline with new methods for cross-domain calls), but so far the only one given. - I think at this point we have to include this functionality and the only potential open issue is if we want to rename it to something other than oauth_token. - Including this functionality doesn't mean we should encourage it, and the way to deal with that is to mark this as 'deprecated'. 2. Should the spec support sending authentication parameters in the body? - I don't have any use cases where this is required. If the client can perform a POST with a body, it should be able to set the header. Where is this an issue? 3. Should the oauth_token parameter be defined as part of an extensible framework for adding parameters to protected resources endpoint? - This was the original issue raised and so far no one has provided any use cases for this. We just need to make sure we pick the right parameter name for oauth_token and clearly state that it is not the right way to send tokens. There should not be any more such parameters in the protected resource namespace. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, March 10, 2011 10:15 AM > To: Richer, Justin P. > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > -1. It is a BAD security practice to pass credentials in URLs. Avoid it. > > Phil > phil.h...@oracle.com > > > > > On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote: > > > Ah, here we run into the classic argument of usability vs. security, in > > which > usability will win every single time in practice. If we don't define at least > a > reasonable way to do this within the scope of OAuth, that's not going to stop > people from doing it. It's just going to make people do it in a million > different > ways, each with their own unique problems that nobody's thought of. At > least this way, we can enable it and have a real discussion about the security > considerations. There are valid and valuable places where putting credentials > in the URL is a reasonable security tradeoff. Not everything functions over > the public internet as well, and the security considerations are different in > these other environments. > > > > In short: yes, it's necessary and good to do this. > > > > -- Justin > > ________________________________________ > > From: William J. Mills [wmi...@yahoo-inc.com] > > Sent: Thursday, March 10, 2011 12:59 PM > > To: Richer, Justin P.; Lukas Rosenstock > > Cc: Brian Eaton; OAuth WG > > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > > > Yeah, but there are serious security problems with credentials in the URL, > > is > it really worth it in light of those problems? > > > > ________________________________ > > From: "Richer, Justin P." <jric...@mitre.org> > > To: Lukas Rosenstock <l...@lukasrosenstock.net>; William J. Mills > <wmi...@yahoo-inc.com> > > Cc: Brian Eaton <bea...@google.com>; OAuth WG <oauth@ietf.org> > > Sent: Thursday, March 10, 2011 9:49 AM > > Subject: RE: [OAUTH-WG] OAuth Bearer Token draft > > > > Yes, there are many development setups where all you can reasonably > access is the URL to get. It's also much simpler to make use of the well- > supported syntax helpers for query parameters instead of relying on new, > custom formatting for newly-defined headers. The bearer token makes this > simple by just having the value of the token, but other schemes have their > own name/value pair formats and encodings that will inevitably cause > hiccups. > > > > -- Justin > > ________________________________________ > > From: Lukas Rosenstock > [l...@lukasrosenstock.net<mailto:l...@lukasrosenstock.net>] > > Sent: Thursday, March 10, 2011 11:49 AM > > To: William J. Mills > > Cc: Brian Eaton; Richer, Justin P.; OAuth WG > > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > > > JSON-P (callback) works with <script> tags where no parameters can be > set; this is used a lot in web applications that want to consume 3rd party > APIs > directly on the client side. So, yes, an alternative for the Authorization > header is required - a.f.a.i.k this use case was one of the driving forces > behind WRAP and bearer tokens. > > > > 2011/3/9 William J. Mills <wmi...@yahoo-inc.com<mailto:wmills@yahoo- > inc.com><mailto:wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>>> > > Is there really a need going forward for anything beyond using the > Authorization header? Do we have clients out there that just can't set that > header? Putting bearer tokens in query arguments is a very bad idea for > many reasons, and in form variables has it's own set of badness (although > not to the same level). > > > > -bill > > > > > > > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
