Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

Jim Manico <jim@manicode.com> Sat, 12 August 2017 19:00 UTC

Return-Path: <jim@manicode.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232091321AE for <oauth@ietfa.amsl.com>; Sat, 12 Aug 2017 12:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
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 zDpUg-zWd-SI for <oauth@ietfa.amsl.com>; Sat, 12 Aug 2017 12:00:28 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 DFF6C132623 for <oauth@ietf.org>; Sat, 12 Aug 2017 12:00:25 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id g131so57363230oic.3 for <oauth@ietf.org>; Sat, 12 Aug 2017 12:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9InTjmWUbJE2s40s8QsIHy2sJZAsBPzKZGHrP3KLSM0=; b=NxxcKpOtDkr8/dR2S9Sy+iCPUiVgr/1qJGd6ykk39UReC/U+NjZnQHJnya3AK0sET2 kGx833FJ5lKTso5c3Y5f8hQ05x6Q31oKG10lRYV3noZtWQZrg1iHP0e1zUiMWoNS/3ss HOvodb3j8uymkEeIc8Lu8WPqjwFBfVtbHPTGeBjKwQoR3WdL3slfjVd0ZbkW3NbkW+VD uoRdLkxJhqtM9sQ0qIrMskjsuH7A6arTHdslEiFL+PAe5pU4SC2EWMMPxy9dqi/9XT0o omDo6qwPzK5P/iUNugJS3vRAHBf1On8XfgUo/VJB6+sUGrnaAGp/TaxAb47H7uXC9bMH Lnaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9InTjmWUbJE2s40s8QsIHy2sJZAsBPzKZGHrP3KLSM0=; b=cL95AMOCh+YyNWIwU9KQ37I0MoAKO7tWXXgYXz8rERbqSqLwXncvqVXBtou4eirZHK /V5xxOmcOdmJSE04P3I77zdYLh2Y5VWHAwvGpZ2RpYmDQjT49JKMZ2rTMkqdE1Gx7IWS X+D9qV5Q7jaueO7o1rE07QL4LyIz1NXlQmnPawz7+90W8qo8OAE1HS2+EHcAjIz8jny9 B0v6XJ2lnGdU9zXbyjysz0UrF3O/Erpu3x4sChnLfeEpdXOZqC0ZMt5zLGU6yyzapEHa B1xJ1lMYuYS5EZx41fwqETKorKR9CL16In4bD/acdhA8fL5iu7zQL4pOAGhRxztEVr48 bQDw==
X-Gm-Message-State: AHYfb5jgZEQFuxSxENM4ZukKzPVq5gg/MN272NBCz4D2w30VV+t38ra+ X9xHHWfSFtXlgPhjoplYZw==
X-Received: by 10.202.7.1 with SMTP id 1mr24730466oih.192.1502564425047; Sat, 12 Aug 2017 12:00:25 -0700 (PDT)
Received: from [10.97.108.8] (mobile-107-92-61-161.mycingular.net. [107.92.61.161]) by smtp.gmail.com with ESMTPSA id d203sm3923849oif.56.2017.08.12.12.00.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 12:00:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7E3A6E44-B243-4508-8311-6ED4B29E8D99
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CAANoGhLjM7VM7FACXdGz0PnN32UTrceOVHeL2x8uiWBs+e1QNA@mail.gmail.com>
Date: Sat, 12 Aug 2017 14:00:22 -0500
Cc: IETF oauth WG <oauth@ietf.org>, jmandel@gmail.com
Content-Transfer-Encoding: 7bit
Message-Id: <4127E319-E8F0-4D87-8D7B-7E5F607AB2BE@manicode.com>
References: <CANSMLKFFGitCa6f5bqR=Ks-kqf_t=3poFwCMWTtJ=MyvNKUL3A@mail.gmail.com> <CANSMLKGV6O7rJJPtPxP44598rz-RXt4rqt0kGrvtUKsN2DD_jw@mail.gmail.com> <C1EC66B5-5171-4393-ABA5-C3B36C5FB9F4@ve7jtb.com> <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> <CAANoGhLjM7VM7FACXdGz0PnN32UTrceOVHeL2x8uiWBs+e1QNA@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZE1Ptf8X2nNpM_8OV1IlkbV_fto>
Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 12 Aug 2017 19:00:35 -0000

> Get is mostly OK with the correct headers to stop referrer leakage.

Those work in new-ish browsers only. Referrer is only one GET leakage vector.

>  Fragment should only be used with real JS clients in the browser and not with servers.  

Fragment behavior is very different in modern browsers, which is one reason why many security folks recommend against the implicit grant type. (I'll double check on this one)

Respectfully,
--
Jim Manico
@Manicode

> On Aug 12, 2017, at 11:43 AM, John Bradley <ve7jtb@ve7jtb.com>; wrote:
> 
> From a interoperability perspective accepting both is best.   
> 
> Get is mostly OK with the correct headers to stop referer leakage.   Fragment should only be used with real JS clients in the browser and not with servers.  
> 
> That is the general direction of the new security advice.  
> 
> People wanting to use POST should probably follow the connect spec for response mode to be explicit about it.  
> 
> John B. 
> 
>> On Aug 12, 2017 10:55, "Jim Manico" <jim@manicode.com>; wrote:
>> > The safest thing for a client is to accept both.  
>> I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.
>> 
>> Respectfully,
>> Jim
>> 
>> 
>>> On 8/11/17 3:18 PM, John Bradley wrote:
>>> OpenID Connect formally defined a POST response mode.
>>> 
>>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>> 
>>> The OAuth 2 spec docent preclude it.  
>>> 
>>> The safest thing for a client is to accept both.  
>>> The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.
>>> 
>>> Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.
>>> 
>>> That is why Connect defined it and OAuth largely assumes that for code get is OK.
>>> For security GET responses should add headers to prevent referrer from leaking the code.
>>> 
>>> We are adding advice on that to the Security document that is being updated now.
>>> 
>>> John B.
>>> 
>>> 
>>>> On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com>; wrote:
>>>> 
>>>> Fixing my "with this technique" url: it should have been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .
>>>> 
>>>>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com>; wrote:
>>>>> Hi All,
>>>>> 
>>>>> I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation — but citing chapter and verse, the server developer pointed out that https://tools.ietf.org/html/rfc6749#section-1.7 says 
>>>>> 
>>>>>> While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.
>>>>> 
>>>>> Is triggering a POST-based redirect (e.g. with this technique) to the redirect_url (including url query parameters for state and code) indeed considered a "method available via the user-agent to accomplish this redirection"? In other words, should a well-behaved OAuth client be prepared to receive GETs as well as POSTs to its redirect_uri? If so, what would be the considerations for a server choosing between GET and POST?
>>>>> 
>>>>> Best,
>>>>> 
>>>>>   Josh
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.manicode.com