In theory yes, sometimes a token has limited scope. But since a token will often have unlimited scope, it carries the same potential for risk.
I would say one-time use tokens (e.g. grant codes) are really the only things that should be passed by URL. Note that if the client was able to obtain a token from a token server, then it must have been previously been able to send data as headers or forms to obtain a token. So why can't it pass the authorization token using the HTTP Authorization header? I'm missing what the problem is here that leads to needing this security compromise. Phil [email protected] On 2011-03-10, at 1:43 PM, Torsten Lodderstedt wrote: > I would assume refresh token exposure to be less dangerous than the leakage > of uid/password since a refresh tokens is restricted to a scope. > > regards, > Torsten. > > Am 10.03.2011 20:22, schrieb Phil Hunt: >> 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 >> [email protected] >> >> >> >> >> 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 [[email protected]] >>> 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 >>> [email protected] >>> >>> >>> >>> >>> 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 [[email protected]] >>>> 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: [email protected] [mailto:[email protected]] 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 >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> 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 [[email protected]] >>>>>> 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."<[email protected]> >>>>>> To: Lukas Rosenstock<[email protected]>; William J. Mills >>>>> <[email protected]> >>>>>> Cc: Brian Eaton<[email protected]>; OAuth WG<[email protected]> >>>>>> 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 >>>>> [[email protected]<mailto:[email protected]>] >>>>>> 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<[email protected]<mailto:wmills@yahoo- >>>>> inc.com><mailto:[email protected]<mailto:[email protected]>>> >>>>>> 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 >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
