Certainly it should be recommended that bearer tokens have limited
scope, but because the notion of "limited scope" isn't well-defined,
you can't really say that "bearer tokens MUST have limited scope".
When it comes to the *normative* text (i.e., the stuff in capital
letters), we need to cover the general case, which requires the "MUST
implement security, SHOULD use security" pattern. Language about
scope is complementary to this.
--Richard
On Apr 8, 2010, at 5:20 PM, John Kemp wrote:
On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote:
The scope argument doesn't really hold any water, since OAuth isn't
defining the scope that tokens have -- authorization servers could
issue tokens that have the same power as passwords. Not all
implementors are "reasonable" :)
Indeed, you can't ever stop people doing stupid things.
But the "scope argument" (and expiration time) does certainly hold
water. Bearer tokens that have appropriate limitations on usage are
well-known to be useful (see one-time use, or time-limited URLs --
for confirming email subscriptions, for example). Such conditions on
usage are useful irrespective of whether you believe that tokens
should be sent only over SSL/TLS.
Regards,
- johnk
--Richard
On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:
Using a bearer token without a signature over HTTP is not
equivalent to HTTP Basic Auth in the clear.
A bearer token is far less powerful than the user’s password. In
most cases, a MITM who steals the user’s password would be able to
change the user’s password, locking the user out his account.
Passwords are not scoped and allow full access to the user’s
account.
A bearer token (for all reasonable implementations) would never
let the holder change the user’s password. Although we have not
standardized on the concept of scope, presumably, many
implementers will issue Access Tokens that do not grant access to
the entirety of the user’ account.
Another important difference between OAuth2 Access Tokens and HTTP
Basic Auth is that Access Tokens can have a limited lifetime, so a
MITM would only be able to hijack an Access Token for a short
duration.
My recommendation is that the spec recommend that Service
Providers use HTTPS for enhanced security, however in the cases
where using HTTPS is not feasible or desirable, Services Providers
should do one or more of the following:
• Issue access tokens that are less powerful than the user’s
password
• Use signatures
• Issue access tokens with a short lifetime, and use the Refresh
workflow
Allen
On 4/7/10 11:06 PM, "Eran Hammer-Lahav" <[email protected]> wrote:
How about something like this:
When accessing resources using the http URI scheme, clients
SHOULD NOT use and servers SHOULD NOT accept bearer token
requests (unsigned requests) as such a request is equal to
sending unprotected credentials in the clear. Instead, clients
SHOULD obtain and utilize an access token with a matching secret
by sending a signed request. Servers MUST accept signed requests
for protected resources using the http URI scheme.
EHL
On 4/7/10 6:42 PM, "Richard Barnes" <[email protected]> wrote:
You guys are both right: The recommendation I made before is
basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.
--Richard
On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:
Eran
Richard and Lief are describing the same point we had in the past
where Peter surmised the discussion that an *implementation* MUST
support TLS is required for bearer tokens to be compliant, and
that
TLS is recommended for *deployment*
-- Dick
On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
We are looking at this all wrong.
There are two kinds of protected resources OAuth supports:
* http://
* https://
OAuth provides two kinds of token authentication modes:
* bearer token
* token + signature
I don't know how to translate your statement below into text I
can
put in
the draft to answer:
When you access/serve an http:// protected resource you do what?
When you access/serve an https:// protected resource you do
what?
It is not about requiring SSL for bearer token. It is about
what you
can/should do when accessing an http:// resource.
EHL
On 4/7/10 7:09 AM, "Richard Barnes" <[email protected]> wrote:
To re-iterate and clarify Leif's second point, I would be in
favor
of
making TLS:
-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)
This a pretty universal pattern in IETF protocols.
--Richard
On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:
Go implement whatever you want. But the spec should set the
highest
practical bar it can, and requiring HTTPS is trivial.
As a practical note, if the WG reaches consensus to drop
the MUST,
I would
ask the chairs to ask the security area and IESG to provide
guidance whether
they would approve such document. The IESG did not approve
OAuth
1.0a for
publication as an RFC until this was changed to a MUST (for
PLAINTEXT) among
other comments, and that with a strong warning.
There is also an on going effort to improve cookie
security. Do we
really
want OAuth to become the next weakest link?
I emphatically agree.
I suspect that a lot of confusion on this thread is caused by
confusing implementation requirements with deployment
requirements
btw.
Cheers Leif
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
