Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

From: [email-masked]
Date: Fri, 11 Mar 2011 08:01:21 +0000

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-masked]

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-masked]
>> 
>> 
>> 
>> 
>> 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-masked]]
>>> 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-masked]
>>> 
>>> 
>>> 
>>> 
>>> 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-masked]]
>>>> 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

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 11 Mar 2011 08:22:17 -0500

It's not just scoped in the oauth-sense, it's also scoped to the issuing site and can't be replayed against other AS/PR domains in the way that a username/password pair can.

 -- Justin

________________________________________
From: [email-masked] [[email-masked]]
Sent: Friday, March 11, 2011 3:01 AM
To: Phil Hunt
Cc: Richer, Justin P.; OAuth WG
Subject: AW: Re: [OAUTH-WG] OAuth Bearer Token draft

Regards,
Torsten.
------Originalnachricht------
Von: Phil Hunt
An:Lodderstedt, Torsten
Cc:Richer, Justin P.
Cc:OAuth WG

Phil
[email-masked]