Hi,
Am 26.10.2011 05:41, schrieb Bob Van Zant:
I'm going to reiterate what has already been said.
OAuth already supports what you're trying to do. Just request a token
twice, the first time request it with a scope or scopes that allows
these special operations. The second time request it with a scope or
scopes that do not.
In general I really like how simple OAuth 2 is. By working within the
constraints of this simplicity we can keep the protocol simple and
easy to use.
I also very much like the simplicity of the protocol but is this an end
in itself? There are use cases not supported by the protocol at present.
I intended to point this out and raise a discussion. We did not discuss
a solution so far, so we also don't know the impact this may cause to
the protocol.
Justin made a proposal some month ago, which seems reasonable to me:
http://www.ietf.org/mail-archive/web/oauth/current/msg06771.html
I think the multiple tokens use case is relevant for every multi-service
provider.
If a client uses different services of such a provider (e.g. mail, web
storage, telephony, and payment), there are good reasons to use
different tokens for the respective resource servers, e.g. abuse
prevention, service seggragation, privacy protection. This holds
especially true if the services are operated by different business
partners in an ASP model. The problem becomes even more obvious in cloud
scenarios.
With the current capabilities of the authorization code, such a client
must send the user through the OAuth dance twice or more often.
Alternatively, a single token is good to access all service. This means
to trade user experience for security or vice versa. I don't like this.
regards,
Torsten.
-Bob
On Tuesday, October 25, 2011, Dave Rochwerger <da...@quizlet.com
<mailto:da...@quizlet.com>> wrote:
> Hi Dan,
> I think we are going down the wrong path here.
> Basically, you've started with the premise of wanting plain HTTP
scheme (in some circumstances), which has caused you to suggest both
of, firstly, relaxing the only method of encryption in oauth2 and
secondly, to further complicate the protocol by
allowing multiple tokens to be returned.
> OAuth2 (unlike version 1) has no signatures or other encryption - it
relies solely on SSL. Therefore any relaxation of this requirement
breaks security wide open (even in your specific short-term token case).
> I think you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather - Why
do you not want to use SSL?
> With today's computer speeds, there is no reason not to use SSL. The
plain HTTP scheme does not really provide a noticeable enough
performance boost. On a side note, if the likes of Google's SPDY is
anything to go by, the future might always be SSL only anyway.
> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin
<dan.taf...@gettyimages.com <mailto:dan.taf...@gettyimages.com>> wrote:
>
> You're right, if tracking was all we needed then a single token
would suffice. The reason for two tokens has more to do with the fact
that we'd like to allow "protected" operations to be called over plain
http. This opens up the possibility of an attacker intercepting the
token for his own nefarious use. If the only thing that token gave him
access to was relatively benign operations like image search, it would
be an acceptable risk (especially if we have a relatively short
lifespan for the token).
>
>
>
> In contrast, "confidential" operations would only be callable over
https. By requiring a different token for them (and not allowing that
token to be used for unprotected operations) we prevent it from being
intercepted. This design intentionally mimics the way secure and
non-secure http cookies work.
>
>
>
> Oauth today basically requires https for all bearer token
implementations. I would like to see this relaxed somewhat.
>
>
>
> Dan
>
>
>
> From: Dave Rochwerger [mailto:da...@quizlet.com
<mailto:da...@quizlet.com>]
> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
>
>
>
> Is separating this out into 2 different tokens, really the best way
to solve your use case?
>
>
>
> It sounds to me that you simply want to track/log the two types of
accesses differently, which can be done entirely outside of the oauth2
process.
>
> Just bucket your operations into two piles internally and track
appropriately (which you would have to do anyway with scopes).
>
>
>
> Scopes are the specific access that the end user grants to a 3rd
party to access their protected resources.
>
>
>
> When an application, to use your example, asks for the scope
"protected confidential", they are providing those two levels of
access to the 3rd party application. If the user says "allow", then
that application has all the access that those two scopes provides.
>
>
>
> Rather than getting applications to then further choose between two
tokens to simply delineate two sets of operations seems like the wrong
place to be doing this.
>
> i.e., why does the 3rd party application have to choose which token
to use for each set of operations? - the user has already granted
both. The resource server can do whatever tracking/logging it wants
based on the actual operations requested - using the single token in
this case.
>
>
>
> Regards,
>
> Dave
>
>
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin
<dan.taf...@gettyimages.com <mailto:dan.taf...@gettyimages.com>> wrote:
>
> I would like to second Torsten's pitch for the ability to return
multiple access tokens with a single authorization process. The use
case for my company is to segment operatio
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth