Subject: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering

From: Bob Van Zant <[email-masked]>
Date: Tue, 25 Oct 2011 20:41:25 -0700

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 <[email-masked]> 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 <[email-masked]>
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:[email-masked]]
> 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 <[email-masked]>
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

---

From: Dan Taflin <[email-masked]>
Date: Wed, 26 Oct 2011 16:33:53 +0000

Thanks, Bob, you're right and I withdraw my request to allow the return of two tokens.

However, I'm not sure OAuth supports our desired use case of passing "protected" access tokens over plain http, based on my reading of section 10.3: "Access token (as well as any access token type-specific attributes) MUST be kept confidential in transit and storage..." seems to imply TLS.

Dave, we may in fact end up going all SSL for our API, but that would mean giving up on certain advantages plain http offers, not just performance but also cacheability.

Dan

From: Bob Van Zant [mailto:[email-masked]]
Sent: Tuesday, October 25, 2011 8:41 PM
To: Dave Rochwerger
Cc: Dan Taflin; OAuth WG
Subject: Returning two tokens. Was: Re: [OAUTH-WG] Rechartering

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 <[email-masked]<mailto:[email-masked]>> wrote:
> 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).
> 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
> 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 <[email-masked]<mailto:[email-masked]>> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Oct 2011 20:52:12 +0200

Hi,

Am 26.10.2011 05:41, schrieb Bob Van Zant:
> 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.
>
> 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.

> > 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.
> relies solely on SSL. Therefore any relaxation of this requirement 
> breaks security wide open (even in your specific short-term token case).
> > 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 
> <[email-masked] <mailto:[email-masked]>> 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
> >
> >
> >
> > 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 
> <[email-masked] <mailto:[email-masked]>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 28 Oct 2011 16:03:02 -0500

I agree with Torsten that there is a need for supporting the multiple tokens use case.
Such a use case is described in the OAuth 2.0 use cases draft
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.10

Zachary

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Wednesday, October 26, 2011 2:52 PM
To: Bob Van Zant
Cc: OAuth WG; Dan Taflin
Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering

Hi,

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

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth