JSON-P (callback) works with
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
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."
To: Lukas Rosenstock ; William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Thursday, March 10, 2011 9:49 AM
S
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 i
-1. It is a BAD security practice to pass credentials in URLs. Avoid it.
Phil
phil.h...@oracle.com
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 d
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 on
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 o
I'm sure this has been gone over before, so apologies for that, but I haven't
found a clear answer (is there a better way than just Google to search the
mailing list archive, by the way?)
I've been puzzling over this text in 4.2: "... the authentication of the client
is based on the user-agent'
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
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?
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:
Well, for one if you promote this, it becomes general technique. Now you have
uid/passwords
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 [phil.h...@oracle.com]
Sent: Thursday, March 10, 2011 2:01 PM
To: Richer, J
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.
Phi
If people are doign a one-poff internal solution they can do whatever they
want, that doesn't mean it shoudl be part of a security related standard.
From: "Richer, Justin P."
To: Phil Hunt
Cc: William J. Mills ; Lukas Rosenstock
; OAuth WG
Sent: Thursday, Ma
The entire purpose of a standard is to codify the one-off solutions out there
into best practices in different contexts.
-- Justin
From: William J. Mills [wmi...@yahoo-inc.com]
Sent: Thursday, March 10, 2011 2:37 PM
To: Richer, Justin P.; Phil Hunt
Cc: Lu
Yes, a token is a less priveledged thing that uid/password. Some of the big
problems are browser cache (being able to get back to a signed in state after a
sign out), server side logging of credentials because they log the URL, and
proxies caching credentials in URLs. POST variables are signif
We disagree on whether bearer credentials carried in GET parameters can be
considered a best practice.
From: "Richer, Justin P."
To: William J. Mills ; Phil Hunt
Cc: Lukas Rosenstock ; OAuth WG
Sent: Thursday, March 10, 2011 11:41 AM
Subject: RE: [OAUTH-WG] O
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
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
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 previou
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: oau
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
___
OAuth mailing list
OAu
22 matches
Mail list logo
