On 4/9/10 12:29 AM, "Torsten Lodderstedt" <[email protected]> wrote:
> @Brian: I CC'd you because you edit the security considerations document.
>>>> I rather add support for query and post parameters (we are really talking
>>>> about a single parameter, oauth_token, outside the HTTP header), and in a
>>>> few year deprecate it in OAuth 3.0. The benefit of these features is that
>>>>
>>>>
>>> I didn't argue against passing tokens as parameters. I just said: "don't
>>> include it in the standard, please". I still don't see any benefit -
>>> just confusion.
>>>
>> I think the majority of working group members would argue that forcing
>> developers to read another spec for a feature they already have in OAuth
>> 1.0a and will rely upon in OAuth 2.0 is more confusing.
>>
>
> As far as I know, OAuth 1.0a did not support bearer tokens.
Sure it did. Not cleanly (the RFC version fixed that) but since there is no
requirement to have a token secret, the PLAINTEXT method could easily be
used as a bearer token.
>>
>>> Moreover as I already pointed out, query parameters are dangerous from a
>>> security standpoint. Do you really want to standardize something like
>>> that? Or do you want to improve internet security?
>>>
>> Not always. We will document the issues and offer suggestions on how to
>> mitigate that. The entire spec relies heavily on implementation details and
>> this falls right into that.
>>
>
> Interesting, who decides when security is a major point and when not?
The working group using rough consensus.
> I would like to cite your statement on "HTTPS requirement for using an
> Access Token without signatures"
Yeah, and I "lost" the argument. Consensus clearly pointed towards not
mandating HTTPS for bearer tokens with clearly explaining the risks in doing
so and highlighting the ways in which servers can reduce risks.
> You mentioned token abuse. Based on my experiences, I assess the
> propability an OAuth token is spread and thus revealed over
> Referer-Headers much higher than someone wiretapping a token on transit
> over HTTP.
>
> Suppose someone kicks off a browser windows using an URL with bearer
> token as parameter. When implemented naively, every HTTP request
> triggerd by the user clicking a link on that site will carry the URL
> including the token in its Referer-Header. So the token becomes
> available to all web sites that can be reached from that point. The
> target site can mitigate that risk by redirecting to itsself, but how
> many site developers are familiar with that topic?
>
> Where will these risk be document? The current draft does not cover
> "using a token".
We haven't reach the security consideration part of the specification,
though some are already collecting material.
I think your concerns about exposing tokens included in the URI query are
justified, but it is far less complicated than you portrait it. Initially,
OAuth calls made by the browser are more likely to happen through JS code
requesting JSON data than the browser opening a web page using OAuth as
access control.
If OAuth ever gets to the point where it replaces Basic auth in the browser,
or used instead of other cookie-based authentication systems, it will gain
native browser support which will use the header exclusively. Until then, JS
code cannot make OAuth requests without other ways to send the token.
>>
>>>> they allow existing browsers to deploy OAuth *today*.
>>>>
>>>>
>>> I don't understand this. Would you please give examples? Browsers today
>>> natively support BASIC/DIGEST/SPNEGO with authorization headers, they
>>> could do this the same way for OAUTH.
>>>
>> Facebook and Yahoo! (as an example) have about 400-500 million users today.
>> They want to deploy OAuth 2.0 within a few months. Clearly expecting these
>> users to upgrade their browser to a version not likely to be available for a
>> year isn't practical.
>>
>
> Impressive numbers! I'm eager to learn the usage scenario which directly
> involves the browser and requires query parameters. Here at Deutsche
> Telekom we operate a token service based on a combination of OAuth 1.0a
> and proprietary mechanisms with a charactiericts similar to OAUTH2. We
> use this service to secure internet products for the german customers
> (>40 million). Service requests use Authorization headers only (e.g.
> for security reasons). I would like to learn whether we missed something.
How about a Twitter client written completely in JS running the browser?
Widgets loading OAuth-protected data in a social network page? There are
plenty of such examples.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
