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

Josh Mandel <> Fri, 06 February 2015 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 366181A8898 for <>; Fri, 6 Feb 2015 13:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rdr0eisxhTNv for <>; Fri, 6 Feb 2015 13:41:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B347A1A888A for <>; Fri, 6 Feb 2015 13:41:06 -0800 (PST)
Received: by with SMTP id a141so14174139oig.5 for <>; Fri, 06 Feb 2015 13:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J4EzFZqA32+5NvqMLx+WChupfSnU5tsCiTdqsqiAY0M=; b=nLNc0kjboBf7mvWZztTNeOAC8pqmVeouGtRsoxt+ZUfatOF04DpGAR9EGAPsCpHv61 20vZKeJjflCiilgUrw1cjxvxFlEwWd9lYmkHJLpdbUojM+wBMSJlv9V3cu51yvXCbBbn D8hl4MJgL2ueMLb+OTi8elj06DYZ2d6TY04eIbooById8TO0PFm6A/Bv6oMYLkGp+2cy wKw0TJRyjeWSPk3+OujLQ1w6xg4CZbeaHhY+903cIec7BqkdFtytMXytmOSh9UGJfrhf KK93yLi9t7V9HCJZAxh5EsqzWdD/BjJzusjHUNLOXlZjBPxhbYUfsa7+miSuwhvkfYjG /dag==
X-Received: by with SMTP id v10mr3921994oeo.46.1423258865978; Fri, 06 Feb 2015 13:41:05 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Feb 2015 13:40:45 -0800 (PST)
In-Reply-To: <>
References: <>
From: Josh Mandel <>
Date: Fri, 06 Feb 2015 13:40:45 -0800
Message-ID: <>
To: Adam Lewis <>
Content-Type: multipart/alternative; boundary="001a11330cbe2150a9050e7247f5"
Archived-At: <>
Cc: OAuth WG <>
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: Fri, 06 Feb 2015 21:41:33 -0000

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 grant):

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 point.)

Hope this helps,


On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis <
> 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