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

John Bradley <ve7jtb@ve7jtb.com> Mon, 09 February 2015 22:59 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 435C81A8A67 for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 14:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5icDTZ-WerhC for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 14:59:10 -0800 (PST)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (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 E1C051A8940 for <oauth@ietf.org>; Mon, 9 Feb 2015 14:59:09 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id m20so11595710qcx.8 for <oauth@ietf.org>; Mon, 09 Feb 2015 14:59:09 -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=/BaTIo9NHTOMzjH6YyVONxfhwZZ1D16r/o0wgz9hPkw=; b=LtqthMJluhbDyui2HjvBXA9FEdlon2qh19oztV6sa/sJ6ViAE07FO/tTElg9KroS+X tiL84thxMkLeLTLdxd9yO52+pnBIZkmxdYcItZusjqxXAeCMaVzOg73hm9511rxYZFHW PogJ3OEjjxoWIb687zCwuz4669TVjGElAt90+2Pcf+psmhPntPwsO7F4mvb5FFflbWGT cr2uVLIkq+GSns3TxIhL1U3l7drzRog2PfXLgwCkZLZkRPBCKWY0j3EgJT4wEcWldGSK A8JyY1WOAsSHtUYKrOGnOTGQYA7dfa+n8mL/2FKoLSqjiUK68QZJuQZe9pVg1/nCjMJ0 w31Q==
X-Gm-Message-State: ALoCoQkx6+Zkh98U2Wr6xKQWcd9XftD6+Qs8DRyAv8ERXVVopHNVybhLOzvxNK4uD/A3pgzEKYaQ
X-Received: by 10.140.106.228 with SMTP id e91mr43847019qgf.19.1423522748952; Mon, 09 Feb 2015 14:59:08 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id 34sm13246429qgh.28.2015.02.09.14.59.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 14:59:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B98BFEE9-5417-4824-BFF1-3C5CFA4CADFF"; 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: <54D93578.9050105@redhat.com>
Date: Mon, 9 Feb 2015 19:59:04 -0300
Message-Id: <61E85A1A-E52C-4709-A1A4-791E4141B8B1@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>
To: Bill Burke <bburke@redhat.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/8CjRIEeDVpv8oIBAuJ1SUVcQpOw>
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: Mon, 09 Feb 2015 22:59:12 -0000

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 http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

The spec for response mode is here http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.

John B.
> On Feb 9, 2015, at 7:32 PM, Bill Burke <bburke@redhat.com> 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
> http://bill.burkecentral.com