To scope a refresh token is good practice (IMHO). I agree with wrt URI query parameters. This should be used carefully and only if no other option exists.
Regards, Torsten. ------Originalnachricht------ Von: Phil Hunt An:Lodderstedt, Torsten Cc:Richer, Justin P. Cc:OAuth WG Betreff: Re: [OAUTH-WG] OAuth Bearer Token draft Gesendet: 10. Mrz. 2011 23:31 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. Gesendet mit BlackBerry® Webmail von Telekom Deutschland _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
