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

John Bradley <ve7jtb@ve7jtb.com> Tue, 10 February 2015 14:50 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 5F37F1A8A92 for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 06:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, 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 0TtbCplNSHsN for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 06:50:13 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 557161A7013 for <oauth@ietf.org>; Tue, 10 Feb 2015 06:49:39 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id x3so28696299qcv.3 for <oauth@ietf.org>; Tue, 10 Feb 2015 06:49:38 -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=6BmIbcN8rUdeHCz0V9qDdetM0Y5JmhWcbRfXmVKi+A8=; b=V8p5ndT9QtRpU55ZlvjI0h5JTYgIyDAy2QZ8g1Tws1T5PLC3Pm8tFzfLCDwK/4Hba3 3ltPIMk49J7avR0gEvmltxcRPlurVJ1I8Hr2kVCl4bujOLaetXj6KImO3MjqCl7dfrv+ mc0WUtKZzzV8iAZXHOIjPDe8uy/b/mCIyI/rC894QCRmMhylzIEjGFrLfMsEsZE2uNEX IZcJf8JqOjA8dA8D+liBUwR8mPF30NZvnc+33iQ10ElaP/1eIXCkjUDlI/NywTeBdJuH JirzfcN0oSKIl6lSSOhYHyYfRvpdkg5Jxs8s0Z7tPXEnYTLZ6KD8W8Mm2qMiEH88Ld+y JgOg==
X-Gm-Message-State: ALoCoQkrHZse2Oan+ODGBju9w3FCI1fN8wYlRv/Gwjbu0bcZokg+ewR/qf3o3oe/0H87bNQVW+m1
X-Received: by 10.229.102.68 with SMTP id f4mr54209695qco.15.1423579778347; Tue, 10 Feb 2015 06:49:38 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id z7sm7108846qah.30.2015.02.10.06.49.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 06:49:37 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_959A1F42-CDE2-4EF6-AC9A-BF94DE2956C8"; 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: <54DA154C.2070700@redhat.com>
Date: Tue, 10 Feb 2015 11:49:33 -0300
Message-Id: <9F3B04D0-3BE6-4AFD-ADA0-91137B023864@ve7jtb.com>
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com> <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com> <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> <FD337176-C292-4688-9CFA-A3C7DF40FCA2@ve7jtb.com> <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> <54D9DA7E.8010606@gmail.com> <F5AB5DA8-8F07-4146-86E0-049B965ECAB3@ve7jtb.com> <54DA154C.2070700@redhat.com>
To: Bill Burke <bburke@redhat.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/AmNpMFPbIMa3Jt7fmpVJjRkW0bA>
Cc: 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: Tue, 10 Feb 2015 14:50:19 -0000

The nonce allows the client to insert a unique value into the id_token  to associate it with a particular browser session(Think SAML RequstID).   
That is useful for web server based clients.  It may or may not be useful in the JS case, as the client is the browser.

While code can only be used once, that doesn't stop someone from  intercepting a code/id_token from one session and replaying it in a different one to the same client.   

In the JS client case that would require a man in the middle between the browser and the AS, so is much harder for an attacker than the case where the client is a web server.

Using the PKCE code_challenge also lets the client detect if some substitution of the code has happened.

John B.
> On Feb 10, 2015, at 11:27 AM, Bill Burke <bburke@redhat.com> wrote:
> 
> 
> 
> On 2/10/2015 8:15 AM, John Bradley wrote:
>> 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              [http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
>> code_challenge=(challenge value)        [ https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
>> code_challenge_method=S256
>> 
> 
> Excellent.  Thanks.
> 
> 
>> 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.
>> 
> 
> Why would you need the nonce if the IDP guarantees that the code can only be used once?  The code, state, and redirect-uri are all validated by the IDP with the access token request.
> 
> Bill
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth