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

John Bradley <> Tue, 10 February 2015 13:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E19C1A0204 for <>; Tue, 10 Feb 2015 05:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJDKYxF1fOdf for <>; Tue, 10 Feb 2015 05:15:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE0FB1A01F2 for <>; Tue, 10 Feb 2015 05:15:14 -0800 (PST)
Received: by with SMTP id c9so28333802qcz.6 for <>; Tue, 10 Feb 2015 05:15:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=q5Y7Xv4GbiL3DFMjbn3J9BSA7kpNscpQdIAKuLaTaFg=; b=k6o14vmw9AQZnqEMlkzfBgKU86JskYA82wwNXL5yNhG7zppjNnIlRqUZfPj0cZj3WR AN3JhlCMxpcP/Re3LnQqQetiw5TZS3x3WlWt68FY6jTjYkoJUT8bCFRmBn9xKwDse+sw U+iTKZWV43tIhaA52q8mglWAqyrMrpp8bo/2JKApElXM2SJpTmLZIBakfHFejKvLSFM4 EmI0rkHma1SHuKuB1PpEAhQpzSzNf85nyAuZM34/3Le2rYedPHaFpfKLxjRsfI0LAr8F x2ff9qkEqmpondVL5j+Mi1p+w8NG5Ub+zSsUJLc4y5PU3pQsHmdU3iUuEKQUlLqeqXjK Ktew==
X-Gm-Message-State: ALoCoQkH1Po6Wy+5w1lu8zPevS5oh/VOnc96fqqgeuvRs4QMYfEIdFXd9EMa5QrkQ65bu0Nb4EiO
X-Received: by with SMTP id w7mr53384055qaj.6.1423574113927; Tue, 10 Feb 2015 05:15:13 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 34sm15135241qgh.28.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 05:15:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_54AB1EF1-7196-4781-BE3E-49FF6DB4E503"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Tue, 10 Feb 2015 10:15:08 -0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Sergey Beryozkin <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
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: Tue, 10 Feb 2015 13:15:30 -0000

The issue is maintaining key material in the browser.

Web Crypto will help with that , but is not deployed widely in browsers at the moment.

Thinking about it a bit someone could make a more secure flow for JS clients using code and some Connect extensions now.

If I were concerned about logging the AT, then I would have the JS make a CORS call to the authorization endpoint with:
response_type=code+id_token              []
code_challenge=(challenge value)        []

The response is fragment encoded,  and the id_token contains a detached sig of code for the JS to verify along with the client as the "aud" signed with RSA key of the AS as the default.
The JS would be the callback URI and extract the code and id_tokens

The JS then makes a CORS call to the token_endpoint sending
code_verifier=(verifier value)

Code could be logged but wouldn't be usable without knowing the code_verifier.
This effectively turns the JS into a semi confidential client.    

We have been looking at PKCE/SPOP for native apps, but nothing would stop it from working with JS clients.

In Connect the JS client crates a nonce value and sends that with the request.  That value comes back in the signed_id token allowing the JS to know that the code and id_token are in reply to it's request and not replayed from another session.

I think using token binding to associate the JS clients TLS key to the AT so that it cannot be replayed from a different browser is the best option over the longer term.
That provides the best protection from plugins and scripts extracting the AT from the running JS.

John B.

> On Feb 10, 2015, at 7:16 AM, Sergey Beryozkin <> wrote:
> Hi John
> On 09/02/15 22:59, John Bradley wrote:
>> The security problem was people only doing host name matching on redirect_uri and attackers finding redirectors to use.   That impacted all public clients not just implicit.
>> Implicit took most of the heat because that was what Facebook was using, and they had the largest issue.
>> Connect has a response_mode that allows the response to be form encoded rather than fragment.
>> I read RFC 5849 as only allowing code to be query encoded.   The response_mode was intended for the new response types we defined in
>> The spec for response mode is here
>> We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.
> What is your opinion on providing a feature 'symmetric' to the one where a signed and/or encrypted code request is passed to AS ? The feature would return a signed and/or encrypted code in the redirect URI as usual.
> I'm not sure it would help the implicit clients though...Unless the encryption key can be derived from a combination of the client_id and some extra piece of information encoded in the JS script but also known to AS (via the registration, etc)
> Thanks, Sergey
>> John B.
>>> On Feb 9, 2015, at 7:32 PM, Bill Burke <> wrote:
>>> On 2/9/2015 5:03 PM, John Bradley wrote:
>>>> OK, I don't know if the WG has discussed the issue of fragments in browser history.
>>>> So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?
>>> Yes, bookmarking tokens is a little scary, IMO, as we've already run into users bookmarking URLs with codes in them.
>>> Also, wasn't there additional security vulnerabilities surrounding implicit flow?  Maybe these were just the product of incorrect implementations, I don't remember, it was a while ago.
>>>> One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs.
>>> It looks like OIDC added a "response_mode" parameter where you can specify "query" or "fragment".  Thanks for pointing this out!
>>> Thanks for all the help.
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list