IETF Logo Mail Archive

Re: [OAUTH-WG] Confusion on Implicit Grant flow

John Bradley <ve7jtb@ve7jtb.com> Fri, 06 February 2015 21:37 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 533711A8870 for <oauth@ietfa.amsl.com>; Fri, 6 Feb 2015 13:37: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, HTML_MESSAGE=0.001, 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 LTB9oBDbNJjl for <oauth@ietfa.amsl.com>; Fri, 6 Feb 2015 13:37:46 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945801A879B for <oauth@ietf.org>; Fri, 6 Feb 2015 13:37:45 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id r5so14124382qcx.11 for <oauth@ietf.org>; Fri, 06 Feb 2015 13:37:44 -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=WszxFu+ehtKw0ARLro4rLWoQA7eocgpf2+f97f86dL0=; b=Jbx02eQ1WJp8Up5JLqhta+NeXbF2RefTCIbQ0pwUuO4Zy/2hIRvBKus8pi+MWnVY2S rejI3hymNdZv7ToXY/Z3941iZyAJmtz6S2HRn1scHUcAkaaZGXcKBB6BFSJYNs6wdUlV 9UjCtQmDZWZvTc3rxjw5611Euv+VIAl2agIlRISGnVvYj+WDKMbX6qalNRbNG5L/igwk ASnrtBzE1VymD6u3E+SUpGJSfKVwUSRfUaZdyCb+SGfU6GxCEtkF5dpdGU1d7yI9j1q1 voRSlXSBCQizgiqJY7tk+wdpuBkq3Ml1a44XJwgxUwktMifv6gXw7T9c3NJ8zGkhngqG 64/w==
X-Gm-Message-State: ALoCoQmIfFjk/FOwJ8BDTYOgUEoXibNbTU8rpgrtFTbmY7TofOppawyRjSktYZ6PxJqxPfrH6aZM
X-Received: by 10.224.161.138 with SMTP id r10mr12766284qax.21.1423258664646; Fri, 06 Feb 2015 13:37:44 -0800 (PST)
Received: from [192.168.1.35] (186-79-116-126.baf.movistar.cl. [186.79.116.126]) by mx.google.com with ESMTPSA id i19sm3792023qaq.19.2015.02.06.13.37.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 13:37:43 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_76147FA7-95A8-4606-A6D6-76859844C8CE"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com>
Date: Fri, 06 Feb 2015 18:37:39 -0300
Message-Id: <5E181E6C-C66B-47AE-BAE6-361C3D4D08C2@ve7jtb.com>
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com>
To: Adam Lewis <Adam.Lewis@motorolasolutions.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/su8UHmPJGuUqh2RzyRI7MN8j-DY>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
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: Fri, 06 Feb 2015 21:37:48 -0000

It isn’t an extra step,  the call back via 302 has to be to a URI in the location header.  The JS loaded by that URI may already be cached in the browser as part of the APP.

The cached JS typically extracts the token and uses it.  The token is never passed to the server where the JS is loaded from. (yes it could be, but if your are doing that then use code or hybrid code+token)

Ther are other ways that could be done using pure Java Script cross origin messaging eg post-message.   However though some people (Google and others) do use that in there custom integrations, a standard for that has not been established.
(there are some real security issues around post message that need to be considered first)

John B.


> On Feb 6, 2015, at 6:27 PM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:
> 
> Hi,
>  
> Having spent most of my time with native apps and web apps, I now am looking at use cases where I need to implement a user-agent-based app.  The Implicit flow seems to be optimized for this.
>  
> To test my understanding, this flow is for a JavaScript client (or similar) executing within a web browser.
>  
> At step (a) the client directs the UA to the authorization server, but the authorization server redirects the UA to a web-hosted client resource.  Why?  It says so that the web-hosted client resources can push javascript (or other) back into the UA so it can extract the access token in the fragment; but some sort of javascript is already running in the browser, since it initiated the authorization request in the first place.  So why this extra step?  Why not treat the javascript client running in the UA like a native app and handle the redirect uri?
>  
> I know this was well thought out when the spec was written, so trying to figure out what I’m missing?
>  
>  
>  
> Tx!
> adam
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

v2.23.0 | Report a Bug | By Email