Return-Path: <david@alkaline-solutions.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 4B8F0120220
 for <oauth@ietfa.amsl.com>; Thu,  4 Jul 2019 18:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 3QF162BXunFm for <oauth@ietfa.amsl.com>;
 Thu,  4 Jul 2019 18:32:53 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com
 [IPv6:2600:3c00::f03c:91ff:fe93:6974])
 by ietfa.amsl.com (Postfix) with ESMTP id F0A2D1201A0
 for <oauth@ietf.org>; Thu,  4 Jul 2019 18:32:52 -0700 (PDT)
Received: from [192.168.1.125] (c-98-246-106-124.hsd1.or.comcast.net
 [98.246.106.124])
 by alkaline-solutions.com (Postfix) with ESMTPSA id 1B66A31765;
 Fri,  5 Jul 2019 01:32:51 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <6FA4E237-3529-4F32-A7DA-D1B801BBED79@alkaline-solutions.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\))
Date: Thu, 4 Jul 2019 18:32:50 -0700
In-Reply-To: <da2a19ae5b66f4284db84938a40a428e@davidsautter.de>
Cc: David Sautter <david.sautter@web.de>,
 oauth@ietf.org
To: david@davidsautter.de
References: <f9e47830-744b-e358-2b13-2bd7de75c513@web.de>
 <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com>
 <da2a19ae5b66f4284db84938a40a428e@davidsautter.de>
X-Mailer: Apple Mail (2.3564)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Eh0MVp-sQxnZGzaBKmJeFSjjt7s>
Subject: Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with
 Microservices
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Jul 2019 01:32:54 -0000


--Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Jul 3, 2019, at 1:44 AM, david@davidsautter.de wrote:

<snip>

> I understood, that you could also secure this variant of the =
Authorization Code Flow with PKCE in order to protect the redirect =
steps. I noticed, that this is rarely discussed "in public" (e.g. blogs, =
Stackoverflow etc) because some people say PKCE is considered to only be =
beneficial in native applications. I know it was invented for protecting =
the IPC steps of those, but why isn't it beneficial to also protect the =
browser redirect steps?

The PKCE guidance is slowly changing. Previously, PKCE was used mostly =
for native apps as the code could be intercepted in between the front =
channel and back channel calls. This is because operating systems do not =
restrict registration of a custom URI scheme to a single application, so =
the redirect back into the application (with the code) could actually go =
to another app.

The security-topics draft (and browser apps draft which refers to it) =
expands this to all code flow. The reasoning is that this replaces some =
of the security mitigations pushed onto the state parameter (such as to =
prevent CSRF) - PKCE is both a more obvious place for it, and a client =
which does not support PKCE correctly is detectable by the AS.

-DW=

--Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 3, 2019, at 1:44 AM, <a =
href=3D"mailto:david@davidsautter.de" class=3D"">david@davidsautter.de</a>=
 wrote:</div><div class=3D""></div></blockquote><div><br =
class=3D""></div>&lt;snip&gt;</div><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><span style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">I understood, that you could also secure this variant of the =
Authorization Code Flow with PKCE in order to protect the redirect =
steps. I noticed, that this is rarely discussed "in public" (e.g. blogs, =
Stackoverflow etc) because some people say PKCE is considered to only be =
beneficial in native applications. I know it was invented for protecting =
the IPC steps of those, but why isn't it beneficial to also protect the =
browser redirect steps?</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div>The PKCE guidance is slowly changing. Previously, PKCE =
was used mostly for native apps as the code could be intercepted in =
between the front channel and back channel calls. This is because =
operating systems do not restrict registration of a custom URI scheme to =
a single application, so the redirect back into the application (with =
the code) could actually go to another app.</div><div><br =
class=3D""></div><div>The security-topics draft (and browser apps draft =
which refers to it) expands this to all code flow. The reasoning is that =
this replaces some of the security mitigations pushed onto the state =
parameter (such as to prevent CSRF) - PKCE is both a more obvious place =
for it, and a client which does not support PKCE correctly is detectable =
by the AS.</div><div><br class=3D""></div><div>-DW</div></body></html>=

--Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35--