Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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, 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.commailto: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.commailto: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.commailto: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
Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
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:b...@veznat.com] 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 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.commailto: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.commailto: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.commailto: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.commailto:dan.taf...@gettyimages.com wrote: I would like to second Torsten's pitch for the ability to return multiple access tokens
Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
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
[OAUTH-WG] Returning two tokens. Was: Re: Rechartering
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
