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

John Bradley <ve7jtb@ve7jtb.com> Sat, 12 August 2017 16:43 UTC

Return-Path: <ve7jtb@ve7jtb.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 9C01412702E for <oauth@ietfa.amsl.com>; Sat, 12 Aug 2017 09:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 q2rOXTefE2sY for <oauth@ietfa.amsl.com>; Sat, 12 Aug 2017 09:43:43 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 2AA14124B0A for <oauth@ietf.org>; Sat, 12 Aug 2017 09:43:43 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id v29so35046417qtv.3 for <oauth@ietf.org>; Sat, 12 Aug 2017 09:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GXs4Ap0TdKrH7PQCVKafBGqONZrtmG8AN71P7axHKoY=; b=RQFogGNAZbH3wwRHAzE+OsZP+Dcm2e/KZdaNNkekQgD4TAFC9HZPVvmvN3MCbmE5wQ zrh4aI++f9Y90TOAnj+r4HqZGVjVghkgtV97EBeoblkoZhTdP1tJdnYdWDofNVnU1d1q KBf9vL0hitKfC6Ih9zGEk69mhA03YKsMIYinCxFgg0h+aUKLzuOTjroBZQSBAJ4cqs0V g/ayxUsp7YdpyqSDIuQB4y4AyPZ9mrDnBZj11dGTyXUX+j8+BUtgB89pvcJCGWpENe21 NYYv8uBkYdedpXoffpgJOs92cutBaYPFnsLkyZm06ywt4h30mSrDLvPblL0362Ije5yk Fy6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GXs4Ap0TdKrH7PQCVKafBGqONZrtmG8AN71P7axHKoY=; b=orDhXCJP9bACng6j93SHUWETCR0FXqZx0gtAdk3Wi1SYPXGl9qMfWKLXCwg+Cp/2DH AdHsvKf0pGBQML6R8YN0RHrmgf5GxXisv41LWydGmwXK24Y0h0XCGDcBHeS7u8chGetd Hot2M7Oz4GlX9nna1GKC3QwWc5DfHLzVv5j0/TjzF7BkRsC9mFrvVQA21BEL766y5HpK Y/lkdBV8O46J+KnRZwE/xWCytRP4n+IDfeW2JDr3YCSLG24bffEyDw3cAK5H0+47hI+q j62vh4ixMx89zVkON5a248qfNxQylTL/b4cgBkVz1ZyDRJ2lZTdCwhMw+J76Lkv+W4+L FH6w==
X-Gm-Message-State: AHYfb5ifKpvHpYveB6GHBzYUGbU6gXekQtzByfM7Tr1F3N8YWYIr/hiJ AtuXGzrElmQnWfK+jvFjzY5uEDsR/8NT
X-Received: by 10.200.42.228 with SMTP id c33mr26106950qta.290.1502556222056; Sat, 12 Aug 2017 09:43:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.101.13 with HTTP; Sat, 12 Aug 2017 09:43:40 -0700 (PDT)
Received: by 10.140.101.13 with HTTP; Sat, 12 Aug 2017 09:43:40 -0700 (PDT)
In-Reply-To: <41d07f67-bb16-1a82-95cb-00b898a5cba2@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>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Sat, 12 Aug 2017 12:43:40 -0400
Message-ID: <CAANoGhLjM7VM7FACXdGz0PnN32UTrceOVHeL2x8uiWBs+e1QNA@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: IETF oauth WG <oauth@ietf.org>, jmandel@gmail.com
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f41bee4b6550556912182"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Ekermxt-0__lDVwxrLchNcuxvZU>
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 16:43:47 -0000

>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/ht
>> ml/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
>
>