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

"Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> Fri, 28 October 2011 21:03 UTC

Return-Path: <zachary.zeltsan@alcatel-lucent.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958ED11E8094 for <oauth@ietfa.amsl.com>; Fri, 28 Oct 2011 14:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+ZtuAINnG-9 for <oauth@ietfa.amsl.com>; Fri, 28 Oct 2011 14:03:10 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E692411E8082 for <oauth@ietf.org>; Fri, 28 Oct 2011 14:03:09 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9SL35V9020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2011 16:03:05 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9SL34rq000703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Oct 2011 16:03:04 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 28 Oct 2011 16:03:04 -0500
From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
To: 'Torsten Lodderstedt' <torsten@lodderstedt.net>, 'Bob Van Zant' <bob@veznat.com>
Date: Fri, 28 Oct 2011 16:03:02 -0500
Thread-Topic: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
Thread-Index: AcyUEGYvUzoXBus/TU6uV/CiQUiI8QBo3FmQ
Message-ID: <5710F82C0E73B04FA559560098BF95B1250BDD1C21@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <CAEDtJsOm+Dfrqsi=9nV017wQCKxRF8hHNRatXLQoJc47Fsajgg@mail.gmail.com> <4EA856DC.9050303@lodderstedt.net>
In-Reply-To: <4EA856DC.9050303@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B1250BDD1C21USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: 'OAuth WG' <oauth@ietf.org>, 'Dan Taflin' <dan.taflin@gettyimages.com>
Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 21:03:13 -0000

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-bounces@ietf.org [mailto:oauth-bounces@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 <daver@quizlet.com<mailto:daver@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.taflin@gettyimages.com<mailto:dan.taflin@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:daver@quizlet.com<mailto:daver@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.taflin@gettyimages.com<mailto:dan.taflin@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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth