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

<philip.kershaw@stfc.ac.uk> Wed, 05 February 2014 09:13 UTC

Return-Path: <philip.kershaw@stfc.ac.uk>
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 2E4ED1A00B0 for <oauth@ietfa.amsl.com>; Wed, 5 Feb 2014 01:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OmXdCVcQ17mU for <oauth@ietfa.amsl.com>; Wed, 5 Feb 2014 01:13:46 -0800 (PST)
Received: from engine29-1277-2.icritical.com (engine29-1277-2.icritical.com [212.57.248.116]) by ietfa.amsl.com (Postfix) with ESMTP id BB7701A00A5 for <oauth@ietf.org>; Wed, 5 Feb 2014 01:13:45 -0800 (PST)
Received: by iCritical outbound mailer at engine29-1277-2.icritical.com for oauth@ietf.org; Wed, 05 Feb 2014 09:13:44 +0000
Received: from engine29-1277-2.icritical.com ([127.0.0.1]) by localhost (engine29-1277-2.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 30868-03 for <oauth@ietf.org>; Wed, 5 Feb 2014 09:13:37 +0000 (GMT)
Received: (qmail 31007 invoked by uid 599); 5 Feb 2014 09:13:37 -0000
Received: from unknown (HELO exchsmtp.stfc.ac.uk) (130.246.236.9) by engine29-1277-2.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 09:13:37 +0000
Received: from EXCHMBX01.fed.cclrc.ac.uk ([169.254.3.132]) by EXCHHUB01.fed.cclrc.ac.uk ([130.246.236.9]) with mapi id 14.02.0318.004; Wed, 5 Feb 2014 09:12:25 +0000
From: philip.kershaw@stfc.ac.uk
To: oauth@ietf.org
Thread-Topic: Suitable grant type for a Javascript use case
Thread-Index: AQHPIlJi6GugnXxeXUGov5NHIis8Cw==
Date: Wed, 05 Feb 2014 09:12:24 +0000
Message-ID: <836226893590734FA88B31162359477F594D26C9@EXCHMBX01.fed.cclrc.ac.uk>
References: <20140204161338.9A4007FC168@rfc-editor.org> <CAD9ie-tGtcBaXbJMkCDswMDhGHNbj+qbawaiXrHowPZFPxzUUQ@mail.gmail.com> <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
In-Reply-To: <1391540170.23334.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.246.121.33]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38E52BC5FB498D4DA936961C56FC758D@fed.cclrc.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: by iCritical at engine29-1277-2.icritical.com
Subject: [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 09:13:48 -0000

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.