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

John Bradley <ve7jtb@ve7jtb.com> Fri, 11 August 2017 20:19 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 E31DC132031 for <oauth@ietfa.amsl.com>; Fri, 11 Aug 2017 13:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 3Cytn6e4iWK7 for <oauth@ietfa.amsl.com>; Fri, 11 Aug 2017 13:19:03 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 30141131E75 for <oauth@ietf.org>; Fri, 11 Aug 2017 13:19:03 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id u139so26313637qka.1 for <oauth@ietf.org>; Fri, 11 Aug 2017 13:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q4BhoEU36nFpPF11KJATGH2pvq/a9jF2c/pWHZGU7iI=; b=akoFA3I9gfQ0l8LqDTT7WkuRuR+sCebz59KM9UjJCEf1AJxGtAf9/uApUVKx/peuVj QxRpNcvawAcVE22ElPrKyZ1Y4EzWCr1ykQ3CUD3huJhKiLqnVJXj1WrCEfyerObnSUFY hp39C6Mz+2BQ6ND7JLrtC6jTrPA2mHaA57jSI0MCB6JuUTGUXogzRd9BFZ9U5ZK5FYcJ g1TqlgJWh+vApViDj5NE7axJuzP7P0P0JDTP7vuMH0GSQ+RR2vtKlYS+n3CnjyZHPoQt R8LOXnX81nX5MqjSNwND8OcV3hIuesQ57p8XoQLfMuZFkUTeve24uunDiUkcAKVr1Zfg ZVSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q4BhoEU36nFpPF11KJATGH2pvq/a9jF2c/pWHZGU7iI=; b=Q+5G4uB+0V64t6CngRqJE0pNoZeXjeYRr3M4ak7aWzxS9NIPsjYAzujuvIOgR2IDik 8AuRJbESHhoP2fQjL9GuHPq9VBPU4FMvlOhI3g2Ijb5uxNxfd6qlH1m12OQkQdxZFP3O k07aLnxQZbAmCy6o6jzNamWh2GLepCvEjS7ZldDuJFtsywbPakoo44GSQ7+jMmrXxZ9r QCjwh1hPDgpYeAVF6i5FZE6kO5Ow7YgmUVkuh6em8E32QVruZwvgobDReIkRBqmVXQbR ei245qHQ9u7JYMPbgPbHqtVz5DEyslO5aRMMUbg1RuFEwLoVnl4NujSrR8LiA1LxpnwN dQvg==
X-Gm-Message-State: AHYfb5hWtBM6zlfCzqVH3TTrPfwUv5GDBMpvGU6jnHg8n5L11ppW1Itz wLuPnvbUI64z4LK8
X-Received: by 10.55.212.2 with SMTP id l2mr14713280qki.3.1502482742021; Fri, 11 Aug 2017 13:19:02 -0700 (PDT)
Received: from [192.168.8.101] ([181.201.218.116]) by smtp.gmail.com with ESMTPSA id y9sm1138821qkg.36.2017.08.11.13.18.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 13:19:00 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <C1EC66B5-5171-4393-ABA5-C3B36C5FB9F4@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 11 Aug 2017 16:18:49 -0400
In-Reply-To: <CANSMLKGV6O7rJJPtPxP44598rz-RXt4rqt0kGrvtUKsN2DD_jw@mail.gmail.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
To: Josh Mandel <jmandel@gmail.com>
References: <CANSMLKFFGitCa6f5bqR=Ks-kqf_t=3poFwCMWTtJ=MyvNKUL3A@mail.gmail.com> <CANSMLKGV6O7rJJPtPxP44598rz-RXt4rqt0kGrvtUKsN2DD_jw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11499ecc2669cb05568006c8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WYOr8u5l5DpsE7OgZcygmuwE2hs>
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: Fri, 11 Aug 2017 20:19:06 -0000

OpenID Connect formally defined a POST response mode.

http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html <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 <https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63> .
> 
> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com <mailto: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 <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)>) 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