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

Sergey Beryozkin <sberyozkin@gmail.com> Tue, 10 February 2015 10:17 UTC

Return-Path: <sberyozkin@gmail.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 A8DA81A6F3C for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 02:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 4ILbmrn_lG8L for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 02:16:57 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 4474B1A1B98 for <oauth@ietf.org>; Tue, 10 Feb 2015 02:16:48 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id l2so6263445wgh.9 for <oauth@ietf.org>; Tue, 10 Feb 2015 02:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KLWtN99hLck7GgDmmhGnwmiIfWx1CXAStcwHi2IecSM=; b=zESXPpeQAHB84VmZozspMU5ogMqXAWOXyXugEXcoYVSIYV5Ob3idxc6HfbXtb8yZke qJDMNVDFDSKHfvBJIA9CLx9HbRKeXDDIjY1lA+dsbHCmEVxch18lnsYbR+Gm1N8Ll9AN eISlBQ2sT00McxWeI/Q44ptVlNx06Wjh0Fcn1uGMrAQnFWzrS3VaGkMdlnl4cJrbre/3 3Jl07w9Ghr262zdF5cEAFOWFdFjIK+sxkxPzCPSb+mHmTERbq2fJ7TgGUqz4UeykoUIc 0yf+ax7xiUOKw6Rrw4+VUYzFj8jIn1BQmVrnNB2exmgzkFIq9izxTFXETIBfoxEOHNFK +hmQ==
X-Received: by 10.194.173.138 with SMTP id bk10mr49116695wjc.112.1423563406941; Tue, 10 Feb 2015 02:16:46 -0800 (PST)
Received: from [192.168.2.7] ([79.97.121.237]) by mx.google.com with ESMTPSA id hz9sm20088567wjb.17.2015.02.10.02.16.46 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 02:16:46 -0800 (PST)
Message-ID: <54D9DA7E.8010606@gmail.com>
Date: Tue, 10 Feb 2015 10:16:30 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
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>
In-Reply-To: <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/IFL-hIqnS8S1oxy3304KMmi3AGc>
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 10:17:05 -0000

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 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.
>
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 <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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>