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

From: "William J. Mills" <[email-masked]>
Date: Thu, 10 Mar 2011 09:59:59 -0800 (PST)

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-masked]>
To: Lukas Rosenstock <[email-masked]>; William J. Mills <[email-masked]>
Cc: Brian Eaton <[email-masked]>; OAuth WG <[email-masked]>
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-masked]]
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-masked]<mailto:[email-masked]>>
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

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Mar 2011 13:07:01 -0500

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

-- Justin
From: Lukas Rosenstock [[email-masked]<mailto:[email-masked]>]

2011/3/9 William J. Mills <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Mar 2011 10:15:28 -0800

-1.  It is a BAD security practice to pass credentials in URLs. Avoid it.

Phil
[email-masked]

On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Mar 2011 11:29:25 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Thursday, March 10, 2011 10:15 AM
> To: Richer, Justin P.
> Cc: OAuth WG
> > 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.
> >
> > Yeah, but there are serious security problems with credentials in the URL, is
> it really worth it in light of those problems?
> >
> > 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-masked]<mailto:[email-masked]>]
> > 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-masked]<mailto:wmills@yahoo-
> inc.com><mailto:[email-masked]<mailto:[email-masked]>>>
> > 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
> >
> >
> >

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Mar 2011 13:27:31 -0500

What about temporary credentials across a local link between controlled systems? My point is just that there are cases where the usual leakage culprits (browsers, proxies, caches, logs) don't apply. 

It's also a bad idea to not use two-way TLS, and it's arguably a bad idea to look at anything on the web without using TLS to begin with, but we still do. It's all about the tradeoff between security of a system and the usability and usefulness of a system. There's an old adage that the most secure computer is powered off and unplugged. :)

I think it's very important to strike an appropriate balance.

 -- Justin
________________________________________
From: Phil Hunt [[email-masked]]
Sent: Thursday, March 10, 2011 1:15 PM
To: Richer, Justin P.
Cc: William J. Mills; Lukas Rosenstock; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

Phil
[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Mar 2011 13:37:05 -0500

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

EHL

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Mar 2011 11:01:27 -0800

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]

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 10 Mar 2011 14:16:36 -0500

I agree with Phil here.

Actually, I hoped that OAuth won't pass credentials in any case and by 
any means--including encryption, period, but I had lost this argument 
long ago. 

Igor

Phil Hunt wrote:
>>>> To: Lukas Rosenstock <[email-masked]>; William J. Mills
>>>>         
>>> <[email-masked]>
>>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Mar 2011 14:17:53 -0500

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

Phil
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Mar 2011 11:22:33 -0800

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]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 10 Mar 2011 22:43:56 +0100

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:
> [email-masked]
>>>>> From: "Richer, Justin P."<[email-masked]>
>>>>> To: Lukas Rosenstock<[email-masked]>; William J. Mills
>>>> <[email-masked]>
>>>>> Cc: Brian Eaton<[email-masked]>; OAuth WG<[email-masked]>
>>>>> JSON-P (callback) works with<script>  tags where no parameters can be
>>>>> 2011/3/9 William J. Mills<[email-masked]<mailto:wmills@yahoo-

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Mar 2011 14:31:23 -0800

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

---

From: George Fletcher <[email-masked]>
Date: Thu, 10 Mar 2011 19:28:14 -0500

I'm not crazy about the compromise either, but it's not possible for a 
site using JSONP and it's cross-domain tricks to set the Authorization 
header out of the browser or POST the data out of the browser in a 
cross-domain way (due to the same origin browser policy).

Quoting Eran from a previous message

    JSON-P is one valid example (though JSON-P usage is in decline with new methods for cross-domain calls)

I do agree we need to give the url parameter a different name than 
oauth_token.

Thanks,
George

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          Home: [email-masked]
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

---

From: Mike Jones <[email-masked]>
Date: Fri, 11 Mar 2011 01:54:00 +0000

Several people have asked for this parameter name to be changed to oauth2_token.  If a change is made, it would seem to me that that would be the logical name to use.

Is anyone strongly opposed to making this change?

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, March 10, 2011 4:28 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

I'm not crazy about the compromise either, but it's not possible for a site using JSONP and it's cross-domain tricks to set the Authorization header out of the browser or POST the data out of the browser in a cross-domain way (due to the same origin browser policy).

JSON-P is one valid example (though JSON-P usage is in decline with new methods for cross-domain calls)
I do agree we need to give the url parameter a different name than oauth_token.

Thanks,
George

Phil

[email-masked]<mailto:[email-masked]>

regards,

Torsten.

Phil

[email-masked]<mailto:[email-masked]>

-- Justin

From: Phil Hunt [[email-masked]<mailto:[email-masked]>]

To: Richer, Justin P.

Phil

[email-masked]<mailto:[email-masked]>

-- Justin

From: Eran Hammer-Lahav [[email-masked]<mailto:[email-masked]>]

Cc: OAuth WG

EHL

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Of Phil Hunt

To: Richer, Justin P.

Cc: OAuth WG

Phil

[email-masked]<mailto:[email-masked]>

-- Justin

From: William J. Mills [[email-masked]<mailto:[email-masked]>]

From: "Richer, Justin P."<[email-masked]><mailto:[email-masked]>

To: Lukas Rosenstock<[email-masked]><mailto:[email-masked]>; William J. Mills

<[email-masked]><mailto:[email-masked]>

Cc: Brian Eaton<[email-masked]><mailto:[email-masked]>; OAuth WG<[email-masked]><mailto:[email-masked]>

hiccups.

-- Justin

From: Lukas Rosenstock

[[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>]

To: William J. Mills

2011/3/9 William J. Mills<[email-masked]<mailto:[email-masked]><mailto:wmills@yahoo-

inc.com><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>>

not to the same level).

-bill

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

Identity Services Engineering     Work: [email-masked]<mailto:[email-masked]>

AOL Inc.                          Home: [email-masked]<mailto:[email-masked]>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 11 Mar 2011 17:05:50 +1100

Justin Richer said: "Since all formats are optional,..."

No they aren't.
draft-ietf-oauth-v2-bearer-03 says
"Resource servers MUST accept [the Authorization header], and MAY support [body & query parameters]"

--
James Manger

---

From: [email-masked]
Date: Fri, 11 Mar 2011 07:56:07 +0000

Why not "bearer_token"? This would be in line with the Authorization scheme name.

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland

---

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

Allow me to rephrase more precisely:

"All formats that people are complaining about are optional".

 -- Justin

________________________________________
From: Manger, James H [[email-masked]]
Sent: Friday, March 11, 2011 1:05 AM
To: Richer, Justin P.; OAuth WG
Subject: RE: [OAUTH-WG] OAuth Bearer Token draft

No they aren't.

--
James Manger

---

From: George Fletcher <[email-masked]>
Date: Mon, 21 Mar 2011 11:50:36 -0400

+1

On 3/11/11 2:56 AM, [email-masked] wrote:
> From: Mike Jones<[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Mar 2011 11:44:04 -0700

+1

Phil
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 Mar 2011 18:17:16 +0000

This suggestion has been adopted in draft 04.

                                                            Thanks all,
                                                            -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, March 21, 2011 11:44 AM
To: George Fletcher
Cc: Mike Jones; [email-masked]; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

+1

Phil

+1

On 3/11/11 2:56 AM, [email-masked]<mailto:[email-masked]> wrote:

regards,

Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland

-----Original Message-----

From: Mike Jones <[email-masked]><mailto:[email-masked]>

Sender: [email-masked]<mailto:[email-masked]>

To: OAuth WG<[email-masked]><mailto:[email-masked]>

OAuth mailing list

OAuth mailing list

--

Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com<http://practicalid.blogspot.com/>