Subject: [OAUTH-WG] Comments on sections 5-7

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 08 Apr 2010 10:54:48 +0200

Hi Eran,

since you are re-working sections 5-7 now, I want to address some  
general issues I see there.

- What is the benefit of including "URI Query Parameter" and  
"Form-Encoded Body Parameter" in the standard? I see OAuth as an HTTP  
authentication scheme similar to BASIC or SPNEGO. All of these schemes  
exclusively use Authorization headers for sending credentials from  
clients to servers. That way, authorization is kept orthogonal from  
the servers API.
Advantages:
+ APIs can be combined with different authentication schemes
+ Libraries can be plugged in and easily add authorization data
+ no name clashes with API parameters
+ can be combined with any HTTP method

It's ok with me if someone wants to send tokens as Query/Body  
Parameters. But then the token parameter becomes a part of the  
resource servers API. Why standardizing that?

 From a security standpoint, sending tokens as query parameter is  
problematic since their are many ways to leak them. Servers typically  
log target URLs in default configurations, GET request URLs are stored  
in browser caches and proxies. And what about Referer-Headers?

When we adopted OAuth 1.0a, the fact that OAuth 1.0a supported three  
different ways of sending tokens caused a lot of confusion. What type  
is supported by what resource server? Do we need to support all of  
them or a sub set? e.t.c.

So IMHO removing 5.1.2 and 5.1.3 would make the standard much simpler  
and easier to understand/implement/use.

Moreover, it should save at least 2 pages.

- I would like to suggest to change section ordering (5-7) in order to  
facilitate readability. From my point of view, the major contribution  
of the OAuth HTTP authentication scheme is the definition of the  
Authorization headers syntax (and semantics). Why not putting this in  
front? Further on, the natural counter part of the Authorization  
header is the WWW-Authenticate header since it is used to advertise  
important properties of the authentication scheme to clients. So I  
would suggest to describe it afterwards.

Based on this considerations, I would suggest the following structure  
(just a sketch):

4 (was 7) Authorization Header
  description of both variants
   token only
   token + signature
  5.2.1 Computing the signature
  security considerations
   e.g. implementations MUST support bearer tokens w/ HTTPS, resource  
servers and clients SHOULD use it
5 (was 6) WWW-Authenticate Header

I'm willed to contribute a more elaborated proposal if you and the WG  
agree with the direction I proposed.

What do you think?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 07:31:07 -0700

While I agree that the spec would be much cleaner with only HTTP header
support, and have tried that approach before, in practice it will cause
significant adoption problems.

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
they allow existing browsers to deploy OAuth *today*.

As for the document structure, it is too early to tell. With OAuth 1.0a I
ended shuffling the sections in draft -09... The spec has to tell a story.

EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 8 Apr 2010 09:38:04 -0700

Agreed with Eran. GET parameters certainly make exploring APIs easier.

On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 08 Apr 2010 22:10:19 +0200

> significant adoption problems.

Can you please give details on that? You removed query and post 
parameters for signed requests. Doesn't this cause adoption problems, too?

> 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.

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?

> 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.

> ended shuffling the sections in draft -09... The spec has to tell a story.

What does this mean with respect to my proposal?

regards,
Torsten.
> EHL
>
>
> On 4/8/10 1:54 AM, "Torsten Lodderstedt"<[email-masked]>  wrote:
>
>    
>> Hi Eran,
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 17:12:11 -0700

> parameters for signed requests. Doesn't this cause adoption problems, too?

There was consensus that signatures are advanced feature where the need for
these methods was low. That is being questioned now.

> include it in the standard, please". I still don't see any benefit -

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.

> 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.

> 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.

> What does this mean with respect to my proposal?

That it is too early for me to use it. I focus on document structure later
in the process. That's how I write.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 09 Apr 2010 09:29:46 +0200

@Brian: I CC'd you because you edit the security considerations document.
> 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.

> this falls right into that.

Interesting, who decides when security is a major point and when not?

I would like to cite your statement on "HTTPS requirement for using an 
Access Token without signatures"
...

I strongly believe we have a responsibility to improve internet security.
The only tool we are given in this working group is calling an
implementation 'not in compliance'. Calling something insecure does not
deter developers from doing stupid things (hence the wide use of Basic auth
where it clearly must not be used per the spec). Calling something
in-compliance when it is not falls under false marketing...

At the end, you are free to deploy whatever you want. But if you are going
to deploy OAuth in an insecure way (regardless of how insecure your other
interfaces are), you don't get say it is compliant. Is anyone here naïve
enough to think that the first time such an insecure OAuth token is stolen
and abused, people will care that it was ignoring the SHOULD? The company
will say that their implementation is in compliance and move the blame on to
OAuth.

---

I fully support your statement.

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".

> users to upgrade their browser to a version not likely to be available for a

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.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 09 Apr 2010 09:34:53 +0200

would you please outline a example?

Am 08.04.2010 18:38, schrieb David Recordon:
> On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav<[email-masked]>  wrote:
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Apr 2010 04:45:26 -0700

> 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.

> Interesting, who decides when security is a major point and when not?

The working group using rough consensus.

> 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.

> Where will these risk be document? The current draft does not cover

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.

> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 12 Apr 2010 20:56:55 +0200

> requirement to have a token secret, the PLAINTEXT method could easily be

And what about the consumer secret? Isn't that required?

> code cannot make OAuth requests without other ways to send the token.

As far as I know, JavaScript code can set headers, incl. Authorization 
Headers, using the operation setRequestHeaders of the XMLHttpRequest 
object 
(https://developer.mozilla.org/en/XMLHttpRequest#setRequestHeader%28%29). Browser 
support would be much better (and would make it easier) but is not 
required.

> Widgets loading OAuth-protected data in a social network page? There are

See above, JavaScript code can set Authorization headers.

Nevertheless, from my point of view, examples discussed in thread 
"Limiting signed requests to use the Authorization request header" 
justify both bearer tokens as well as signed tokens as URI Query Parameters.

I still don't see justification for Form-Encoded Body Parameters.

regards,
Torsten.

---

From: Luke Shepard <[email-masked]>
Date: Mon, 12 Apr 2010 12:00:48 -0700

> Object

XMLHttpRequest is limited to the same domain (example.com can make calls to example.com). When making cross domain requests (example.com requesting data from facebook.com), different techniques must be used. Many of those techniques (such as JSONP) are restricted to just modifying the URL, and cannot set headers or use POST.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 12 Apr 2010 21:09:08 +0200

> XMLHttpRequest is limited to the same domain (example.com can make calls to example.com). When making cross domain requests (example.com requesting data from facebook.com), different techniques mus…
I thought "HTTP Origin Headers" 
(http://www.petefreitag.com/item/702.cfm) would eliminate that restriction?

regards,
Torsten.

---

From: John Kemp <[email-masked]>
Date: Mon, 12 Apr 2010 16:05:32 -0400

On Apr 12, 2010, at 3:09 PM, Torsten Lodderstedt wrote:

> I thought "HTTP Origin Headers" (http://www.petefreitag.com/item/702.cfm) would eliminate that restriction?

Use of the Origin HTTP header and W3C CORS (see https://developer.mozilla.org/En/HTTP_access_control for an explanation and information about Mozilla's support for that) is one of the proposed ways to allow cross-domain requests. There are others, such as the proposed standard Uniform Messaging Policy (http://www.w3.org/TR/UMP/): 

However,

i) Not all browsers support CORS yet (Gecko and Webkit latest builds do, but not their latest stable versions) 
ii) Sites have to "opt-in" in all of these models to allow a cross-domain request, and most sites haven't opted in (cross-domain requests are thus not allowed in most cases) 

So browsers will often have to enforce same-domain requests in the usual way, requiring hacks like JSONP in order to perform cross-site requests, and thus Javascript cannot be (and will not be any time soon) assumed to support the setting of HTTP headers in all cases.

Cheers,

- johnk

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 13 Apr 2010 21:52:15 +0200

> So browsers will often have to enforce same-domain requests in the usual way, requiring hacks like JSONP in order to perform cross-site requests, and thus Javascript cannot be (and will not be any…
thanks for your explanation

regards,
Torsten.