I think I was confused because of the use of the term "credential" rather than token.
If you are calling the token service end-point then it is a big issue. E.g. exposing a refresh token would be as bad as a uid/pwd since it is long-lived. For a resource server, I agree, the risk is lower. Phil phil.h...@oracle.com On 2011-03-10, at 11:17 AM, Richer, Justin P. wrote: > Nobody said UID and password -- we're talking about tokens here. The cost of > a leaked temporary token (even a straight bearer token) is much, much lower. > > -- Justin > ________________________________________ > From: Phil Hunt [phil.h...@oracle.com] > Sent: Thursday, March 10, 2011 2:01 PM > To: Richer, Justin P. > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Well, for one if you promote this, it becomes general technique. Now you have > uid/passwords in browser history etc potentially accessible to javascript and > could be leaked/hacked in any number of ways. > > Also, I would say that credentials are a higher risk item then say a specific > API call. Why? because credentials are used universally and so the exposure > is much higher. That said, it is still possible that application data can > just as costly to expose. Another reason to use secure forms over URLs. > > Phil > phil.h...@oracle.com > > > > > On 2011-03-10, at 10:37 AM, Richer, Justin P. wrote: > >> 1) Yes. And don't discount ease-of-use for developers. If I'm already >> sending my parameters over the query, this becomes another parameter and is >> really easy to manage. >> 2) Yes, for parallelism to #1, when using a POST. >> 3) The idea of a parameter registry for this part is absurd, and the >> parameter should be kept simple. I do think that it needs to be named >> something other than "oauth_token". >> >> I'm happy with discouraging the use of 1 and 2 with discussion in the >> security considerations, but I think that if we don't specify this behavior >> and discuss it, then people are going to do it anyway and we run more risk >> of things going wrong. Simply ignoring the issue in the spec (by remaining >> silent about it) will not make it go away. >> >> Since all formats are optional, couldn't an AS/PR setup that wants to just >> lock things down and require auth headers for their particular setup? If in >> two years nobody deploys it anymore, then let's deprecate it from the spec >> and never speak of this again. >> >> -- Justin >> >> ________________________________________ >> From: Eran Hammer-Lahav [e...@hueniverse.com] >> Sent: Thursday, March 10, 2011 1:29 PM >> To: Phil Hunt; Richer, Justin P. >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] OAuth Bearer Token draft >> >> 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
