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 protected] [mailto:[email protected]] 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).
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
On 3/10/11 5:31 PM, Phil Hunt wrote:
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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.
- 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 protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf
Of Phil Hunt
Sent: Thursday, March 10, 2011 10:15 AM
To: Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
-1. It is a BAD security practice to pass credentials in URLs. Avoid it.
Phil
[email protected]<mailto:[email protected]>
On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote:
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 protected]<mailto:[email protected]>]
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
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 protected]><mailto:[email protected]>
To: Lukas
Rosenstock<[email protected]><mailto:[email protected]>; William
J. Mills
<[email protected]><mailto:[email protected]>
Cc: Brian Eaton<[email protected]><mailto:[email protected]>; OAuth
WG<[email protected]><mailto:[email protected]>
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 protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]>]
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 protected]<mailto:[email protected]><mailto:wmills@yahoo-
inc.com><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]>>>
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
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect AIM: gffletch
Identity Services Engineering Work:
[email protected]<mailto:[email protected]>
AOL Inc. Home:
[email protected]<mailto:[email protected]>
Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
