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

Antonio Sanso <> Thu, 19 February 2015 11:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC52A1A888F for <>; Thu, 19 Feb 2015 03:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2baU6c0GT8UV for <>; Thu, 19 Feb 2015 03:14:29 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::1:665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 792591A8728 for <>; Thu, 19 Feb 2015 03:14:28 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 19 Feb 2015 11:14:06 +0000
Received: from ([]) by ([]) with mapi id 15.01.0087.013; Thu, 19 Feb 2015 11:14:06 +0000
From: Antonio Sanso <>
To: John Bradley <>
Thread-Topic: [OAUTH-WG] Confusion on Implicit Grant flow
Date: Thu, 19 Feb 2015 11:14:06 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032;
x-forefront-prvs: 0492FD61DD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(129404003)(24454002)(189002)(54094003)(479174004)(199003)(122556002)(76176999)(33656002)(19580395003)(16601075003)(87936001)(106356001)(16236675004)(54356999)(40100003)(97736003)(46102003)(99286002)(82746002)(50986999)(86362001)(19580405001)(93886004)(2950100001)(64706001)(83716003)(105586002)(36756003)(102836002)(2656002)(62966003)(110136001)(19617315012)(101416001)(587094005)(2900100001)(68736005)(92566002)(15975445007)(66066001)(77156002)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_593558ADA6214734B4E155345E3C3D96adobecom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2015 11:14:06.0243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Feb 2015 11:14:34 -0000

I wonder if the spec would have contained POST + 307 response rather than a GET+302 with fragment for the implicit grant would have been safer…..

At least the risk of fragment leakage would have been lower...



On Feb 10, 2015, at 6:10 PM, John Bradley <<>> wrote:

On Feb 10, 2015, at 1:12 PM, Adam Lewis <<>> wrote:

Hi John,

What do you mean by the app that is “already loaded and cached in the browser?”  Where did this app come from initially?  Is this what comes from the web-hosted client resource in step D/E of section 4.2?  So the first time D/E *will* flow over the wire, and in all subsequent requests it will be cached?

Yes the web hosted client resource is typically the same JS code that is creating the Authorization request in A.   Now that you mention it the diagram in 4.2 is ambiguous about where that request comes from , the fact that it is coming from the browser implies that it is a JS CORS type request.

In some cases you might have a webserver invoke it via a 302 redirect and load a new JS app from the redirect URI.

The important thing is that the fragment is not sent to the server on the call that loads the JS even if it is not cached.

The thing people do (facebook and others) that is twisting implicit in my opinion is having the callback URI just load a JS snipppet that extracts the token and posts it back to “Web hosted client resource”
Those applications should be using the code flow.

And with respect to the web hosted client resource, is this a resource deployed by the same domain as the RS to facilitate the deployment of user-agent-based apps to access the APIs exposed by that RS?

The hosted client resource is typically a AJAX/AngularJS application that doesn’t want to swap out it’s context by doing a full 302 redirect to the AS.

The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps to protect the API that they use with OAuth, in that case they may all be from the same domain.

It might be that a sophisticated app may have multiple tokens for different API across multiple providers.

John B.


From: OAuth [] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

Typically the implicit callback JS is part of the application that is already loaded and cached in the browser.

The implicit flow doesn’t depend on on the fragment not being re-appended to the resource location URI in the 302.  It would admittedly be more secure if that didn’t happen.
Re-appending the fragment is the correct browser behaviour according to the W3C.

I still think you are farther ahead with that than leaking the code in the referrer.

Implicit if done correctly has the token in one leg.  code on the other hand has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a secret that is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then the answer is different, but the question was for a JS only client.

John B.

On Feb 9, 2015, at 6:21 PM, Prateek Mishra <<>> wrote:

The implicit flow depends upon a subtle and little known aspect of browser behavior - that the URI fragment component isn't propagated across redirects.

I havent checked this recently - but I am aware that several folks have found that some browser versions dont comply with this requirement.

The additional round-trip issue is also unclear. The implicit flow requires an additional redirect (round-trip) to retrieve JS which retrieves the access token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code for the access token?

- prateek

You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.

You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.

So yes using code for that is less secure.

Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.

John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke <><> wrote:

If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.

I'm just trying to figure out if we missed anything...

On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.

On Feb 9, 2015, at 5:05 PM, Bill Burke <><> wrote:

Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.

On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the

implicit flow, but if I'm reading between the lines of your question

correctly, there are two key parts to the answer, because the implicit

flow is designed to accomplish two key goals (vs. the authorization code


1. Shave off one round-trip HTTP request (the step of exchanging a code

for a token)

2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes

advantage of the fact that a URL's "#hash" is not sent to the server

with an HTTP request. By embedding the token in a "#hash", it won't

inadvertently appear in server logs, for example. So with the implicit

flow, I can (for example) statically host a browser-based app at Amazon

S3 without having access tokens leak to Amazon. (Of course, if your

threat model includes a compromised server, then bets are off on this


Hope this helps,


On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis


<><>> wrote:


   __ __

   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?____

   __ __

   __ __

   __ __




   OAuth mailing list<> <><>


OAuth mailing list<>


Bill Burke

JBoss, a division of Red Hat<>


OAuth mailing list<>


Bill Burke

JBoss, a division of Red Hat<>


OAuth mailing list<>

OAuth mailing list<>

OAuth mailing list<>