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. -Bob On Tuesday, October 25, 2011, Dave Rochwerger <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> 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] > 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> 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
