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

Thomas Broyer <t.broyer@gmail.com> Sun, 13 August 2017 15:21 UTC

Return-Path: <t.broyer@gmail.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 3747B13241E for <oauth@ietfa.amsl.com>; Sun, 13 Aug 2017 08:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YO3kZpCT9lqI for <oauth@ietfa.amsl.com>; Sun, 13 Aug 2017 08:21:03 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 2AEFC1323AB for <oauth@ietf.org>; Sun, 13 Aug 2017 08:21:03 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id 16so41572814qtz.4 for <oauth@ietf.org>; Sun, 13 Aug 2017 08:21:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a5PfnvcWt1Mlbn4UjhBQavyhYq2aHRcXMSG6EWfsW8A=; b=YW9a36r0vgxgw3UaaqFa7bnrXIZ93GsC+ddesVSQppudsX6F3rhxHuWSs80sactJGD 9NOX5VfZGRZ7M5JXlSxn59X2+AtQTrS36pyKdDeOIkVH2SdTWWW1vQI193aAd9PQGP9f bOs7FtU5YBNg16yKCKTMd284PLt6OlPFHUx0Bl3o1gtVnumhfJDtw7KbniJ0E4vQ7ILf SyuqPg9TGKoL2Yd7V0Wpn4cCU1uU2IVFRNmrIA8sJCA0nPg7bA9krapzV6kCIh9TFcfz oeOmAvMs9piVHFVCfon+uMwbZcz4jjUMeZfPy1IwDQgFn5qZp0JwtN9m/tKVDbspYfAQ tRMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a5PfnvcWt1Mlbn4UjhBQavyhYq2aHRcXMSG6EWfsW8A=; b=EvEtyyreN2fPvnxqiXbailHjNzULSU4w/QBjalkvPhKLHPnLcfLpx2Wc0xLVeypKVv xEdNFsLWA7XMAqwxUVBdKFY1uM5LH3elEtccCQPSSXYMWRdLITqfZZpI4njmcKcp0D8+ dQijlkcyOu4XL+p3FSLQ5sIOKRHMFn+maeFj+y6KpaC0tVq10mSilKAK8pm6O5uI4hO2 jhye5cVfTucO18j7AJgVwV4ZXrf2Z3/Pb331CGKzvypZDmzhjwvpiesx/bHYVl2+tHdi 6jnNbInj4ZdEye45HTlVOdA0sy/b5MGZDomKbn+ISfy3ocbcKdTZZohSQOTxrkFr0jK3 nLSQ==
X-Gm-Message-State: AHYfb5jRD/cDDVH12QS9E0mgK3Mpe3OPLrzA4eoSQFhRPsr+1iPEB46l 1cngxe6LbgVA0IYJ+VH9J3YaP0wowg==
X-Received: by 10.200.14.72 with SMTP id j8mr29642362qti.124.1502637662351; Sun, 13 Aug 2017 08:21:02 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Sun, 13 Aug 2017 15:20:49 +0000
Message-ID: <CAEayHEMwW4dTs_TXfWCKsQqiihRapf2GyWWiPdTUFBpRFVYt2w@mail.gmail.com>
To: Jim Manico <jim@manicode.com>, John Bradley <ve7jtb@ve7jtb.com>, Josh Mandel <jmandel@gmail.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e08225dac1735730556a41846"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5vDpWI4t5B_33GpsnCB8RY0IJ6k>
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: Sun, 13 Aug 2017 15:21:06 -0000

Rejecting a GET with code in the URL means that the code is never "used" at
the AS, so can still be exchanged for an access token; and rejecting the
request does not mean it won't leak. So reject if you like from the user's
point of view, but "consume" the code anyway (and then immediately revoke
the token, maybe), or you're probably making things worse (if you're
worried of leaking 5min one-time codes, particularly when that code cannot
be used without a client_secret and/or PKCE code_verifier)

Disclaimer: not a security expert here.

Le sam. 12 août 2017 16:55, Jim Manico <jim@manicode.com> a écrit :

> > 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
>> <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63%29>)
>> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>