Re: [OAUTH-WG] Suitable grant type for a Javascript use case

John Bradley <ve7jtb@ve7jtb.com> Wed, 05 February 2014 21:49 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE11A0228 for <oauth@ietfa.amsl.com>; Wed, 5 Feb 2014 13:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6X-c2Cl-Q4 for <oauth@ietfa.amsl.com>; Wed, 5 Feb 2014 13:49:36 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id D79A01A0225 for <oauth@ietf.org>; Wed, 5 Feb 2014 13:49:35 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id x13so1698431qcv.5 for <oauth@ietf.org>; Wed, 05 Feb 2014 13:49:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xyHxNxPzFApqdJqgsR4fHsd9ssKl7vWYU4u7EQLR0cg=; b=PDgZksV5WR8STpDqGJ/x3IqguhjXZGLecyYWZUbaO8B+cW1ejTi1Es7Lk34csOGbYq ZIVuVodD5mWSu9JXUapSCMp1NsMOyr9Yg7fUecqnPKLS77TpQVWz12DievhxP8wGSKxE 2/CVFH1P0+xQZIp51k/g7f+FdqzeQjmhMn5ZujPVF9ldlBK1R/KQR3eB/vmOWrbs6CM4 Sfo899j5Ye6UwIpVtdREHyPyYAaynV52Z6p23s12LSVD4i6AikCdjFjHsbrOE2hxwjLn YgbbLglMIjfO0tYZh9jsK/dQBzzqc60BIJhnfzTGQOYc1pWlxCMYC1VwI+A5xNXiYyiv Ve9Q==
X-Gm-Message-State: ALoCoQm+dJIu9wZDcKKfkYuq/x6SfdvkoScUl5QPLR5MfhMIvjej9+N4YVF4NR0fTxNnHLdgisB/
X-Received: by 10.140.83.112 with SMTP id i103mr6388064qgd.100.1391636974513; Wed, 05 Feb 2014 13:49:34 -0800 (PST)
Received: from [192.168.0.200] ([201.188.15.242]) by mx.google.com with ESMTPSA id j97sm38944447qge.22.2014.02.05.13.49.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 13:49:33 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8C309BB9-AAA1-45E1-A0FD-45605D695C44"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>
Date: Wed, 05 Feb 2014 18:49:09 -0300
Message-Id: <FF14E73A-944D-4830-B270-D44E838604F6@ve7jtb.com>
References: <20140204161338.9A4007FC168@rfc-editor.org> <CAD9ie-tGtcBaXbJMkCDswMDhGHNbj+qbawaiXrHowPZFPxzUUQ@mail.gmail.com> <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com> <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk> <005701cf2265$b77bd120$26737360$@gmx.net> <52F283E4.50507@oracle.com> <6BF381DC-791A-4220-9C95-F0ED0718190B@mitre.org> <52F293AF.50108@oracle.com> <18332002-43F0-4FE3-9587-F1B63CDD7EC3@ve7jtb.com> <836226893590734FA88B31162359477F594D721F@EXCHMBX01.fed.cclrc.ac.uk>
To: philip.kershaw@stfc.ac.uk
X-Mailer: Apple Mail (2.1827)
Cc: "oauth@ietf.org list" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Suitable grant type for a Javascript use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 05 Feb 2014 21:49:41 -0000

You can use PostMessage if you control both the client and AS.

Google uses it in there identity toolkit if you use there g+ Java Script client. http://www.riskcompletefailure.com/2013/03/postmessage-oauth-20.html

There is some example code at https://code.google.com/p/oauth2-postmessage-profile

In OpenID Connect the same technique is used for session management. http://openid.net/specs/openid-connect-session-1_0-18.html

You can do it but it would be custom to your AS.

John B.


On Feb 5, 2014, at 6:22 PM, <philip.kershaw@stfc.ac.uk> <philip.kershaw@stfc.ac.uk> wrote:

> Thanks all - some interesting points raised.
> 
> I've used the Authorisation Code grant for a couple of other use cases on other projects.  The Implicit Grant is less desirable but it fits here for me because of the particular constraints of the client and its hosting environment.  The level of security required is low.
> 
> I'd be interested in finding out about the examples that use a PostMessage approach that you mention John.
> 
> Phil
> 
> On 5 Feb 2014, at 20:33, John Bradley wrote:
> 
>> The implicit flow is intended to get a access code to JS clients in the browser.   It is true that you could use the code flow, but only if the AS token endpoint allowed CORES requests.
>> 
>> Given that the client is in the UA and has a direct TLS connection to the Authorization endpoint, from the clients point of view the call to the authorization endpoint and the call to the token endpoint are equally secure.   
>> 
>> Given that Java Script in the browser typically can't protect a client secret, the two flows are about equal in security for the AS.
>> 
>> It is true that people use implicit for things that they probably shouldn't, but to get a token to Java Script in the UA implicit is probably the best way to do it without jumping through extra hoops that don't add anything.
>> 
>> At some point we need to do a PostMessage binding for Implicit as an option passing the token in the fragment,  many implementations do that today for JS clients but it is not interoperable without a profile.
>> 
>> John B.
>> 
>> 
>> On Feb 5, 2014, at 4:40 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
>> 
>>> Well, there is a fundamental difference between the security properties of implicit vs. code flow: in the former access tokens are passed via URLs (protected only by the fragment URI requirement), whereas in the
>>> latter this is never the case. So I do see a foundational difference in security properties between the two. The core issue the type of artifact exposed in network flows in both the models.
>>> 
>>> Another way to put it would be: the authorization code flow is a re-purposing of the well known SAML SSO Web Artifact profile which has a long history of deployment and use. The implicit flow "simplifies" that but there
>>> are definitely some consequences from a security point of view.
>>> 
>>> I can see that certain low-value clients (or even better, clients for whom the client issuing entity assumes no liability :-) can reasonably utilize the implicit flow. But it would be good if its weaknesses were kept in mind.
>>> 
>>> - prateek
>>>> While you should always factor in an analysis of the security properties of your client, you should also realize that by hosting the client completely inside the browser, most of the benefits of the code flow go away. You're no longer able to separate the knowledge of different parts of the protocol, and so much of what you're protecting with the auth code doesn't actually apply anymore.
>>>> 
>>>> Also, if the user is using a user agent that is not conformant or up to date, there's no need to sniff OAuth because it can just steal the primary credentials from the auth server connection directly -- so the counter argument is a bit of a red herring. Yes, it's a requirement for this to work properly, but it's a requirement for many other things to work properly also.
>>>> 
>>>> -- Justin
>>>> 
>>>> On Feb 5, 2014, at 1:33 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
>>>> 
>>>>> Well, this means you are completely dependent on a security model that is based on a very specific property of HTTP
>>>>> redirects. The User agent MUST NOT forward any component of a fragment URI in a redirect - you are depending on the user having
>>>>> a conformant and uptodate user agent.
>>>>> 
>>>>> I would say that the authorization code grant has more robust security properties. From my perspective depending
>>>>> on this type of subtle and complex requirement on other layers of the protocol stack is a considerable risk.
>>>>> 
>>>>> So you should factor that in your analysis of the security properties of your client.
>>>>> 
>>>>> - prateek
>>>>>> Hi Phil,
>>>>>> 
>>>>>> the server won't see the access-code, cause it is returned within the hash
>>>>>> that stays at the client-site:
>>>>>> 	http://.../returnUri#access_code=ABCDE.
>>>>>> 
>>>>>> By definition, the returnURI has to be the URI that was registered for the
>>>>>> client. IMHO, you are only allowed to add additional URL-Parameters.
>>>>>> 
>>>>>> In my opinion, your use-case suits _very_ well to the implicit flow.
>>>>>> 
>>>>>> Wishes,
>>>>>> Manfred
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von
>>>>>> philip.kershaw@stfc.ac.uk
>>>>>> Gesendet: Mittwoch, 5. Februar 2014 10:12
>>>>>> An: oauth@ietf.org
>>>>>> Betreff: [OAUTH-WG] Suitable grant type for a Javascript use case
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I'm looking to apply OAuth for a particular use case with a Javascript
>>>>>> client and would like to get some guidance with this.  Bear with me as I'm
>>>>>> new to this list.
>>>>>> 
>>>>>> I have a Javascript client which needs to be deployed on a number of
>>>>>> different sites for which we don't have control over the server-side code.
>>>>>> The client needs to obtain an access token to submit data to another 3rd
>>>>>> party site on behalf of the user.
>>>>>> 
>>>>>> We've looked at the Implicit Grant type
>>>>>> (http://tools.ietf.org/html/rfc6749#section-4.2).  Our third party site
>>>>>> hosts an Authorisation server and Resource Server.  The client provides a
>>>>>> redirect URI to return the token to.  My understanding is that the redirect
>>>>>> URI is a security measure to ensure the token is returned to an endpoint
>>>>>> known to the Authorisation Server.
>>>>>> 
>>>>>> However, in my case it is only the Javascript client that needs the token.
>>>>>> I can see how the token can be passed to the Javascript via step E in figure
>>>>>> 4.  However, we have limited control over the site hosting the Javascript
>>>>>> ('Web-hosted Client Resource' in Figure 4).  We can host Javascript but we
>>>>>> can't easily alter any server-side code.  There's a danger that the
>>>>>> server-side code will choke when it receives the redirect the URI containing
>>>>>> the access token.  I'm wondering if there is a suitable workaround for this.
>>>>>> Can we dispense with the redirect URI or does this compromise security too
>>>>>> far?  Perhaps we should be looking at an implementing an alternative grant
>>>>>> type?
>>>>>> 
>>>>>> Any help much appreciated.
>>>>>> 
>>>>>> Cheers,
>>>>>> Phil--
>>>>>> Scanned by iCritical.
>>>>>> _______________________________________________
>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> --
> Scanned by iCritical.