@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.
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?
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".
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.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
