MIME-Version: 1.0
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 27 Dec 2019 12:03:30 -0700
Message-ID: <CA+k3eCRCs3W9th9b01iCJ4c-wEzuovP=GZaTs+cZNyLkOWXLsA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000db4f1a059ab42770"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RucZHKuRf6HCsWUyJDK0XRwub3w>
Subject: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post
 response mode
Precedence: list

--000000000000db4f1a059ab42770
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We have a-sometimes used scenario where a client makes an
authorization/authentication request with a "token id_token" response type
and "form_post" response mode (nonce is also sent and exact redirect URI
matching is done at the AS). The access token is never exposed in any URLs
and access token injection is prevented by the at_hash claim in the id
token.

That seems to me like a legitimate and reasonable usage scenario. However,
it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the
Security BCP-to-be
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.=
1.2>,
which has:

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.

I know this particular text has been discussed over and over again so I
hate to revisit it. But based on the aforementioned scenario I think maybe
it still doesn't quite hit the mark. Access token injection is prevented.
The token leakage scenarios mentioned in that section are all avoided. And
while I know sender-constrained is recommended elsewhere in the draft, it's
not really a realistic option for the majority of deployments.

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000db4f1a059ab42770
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>We have a-sometimes used scenario where a client make=
s an authorization/authentication request with a &quot;token id_token&quot;=
 response type and &quot;form_post&quot; response mode (nonce is also sent =
and exact redirect URI matching is done at the AS). The access token is nev=
er exposed in any URLs and access token injection is prevented by the at_ha=
sh claim in the id token. <br></div><div><br></div><div>That seems to me li=
ke a legitimate and reasonable usage scenario. However, it would fall on th=
e wrong side of the SHOULD NOT in <a href=3D"https://tools.ietf.org/html/dr=
aft-ietf-oauth-security-topics-13#section-3.1.2">Section 3.1.2 of the Secur=
ity BCP-to-be</a>, which has:<br></div><br><div>=C2=A0=C2=A0 In order to av=
oid these issues, clients SHOULD NOT use the implicit<br>=C2=A0 =C2=A0grant=
 (response type &quot;token&quot;) or any other response type issuing<br>=
=C2=A0 =C2=A0access tokens in the authorization response, such as &quot;tok=
en id_token&quot;<br>=C2=A0 =C2=A0and &quot;code token id_token&quot;, unle=
ss the issued access tokens are<br>=C2=A0 =C2=A0sender-constrained and acce=
ss token injection in the authorization<br>=C2=A0 =C2=A0response is prevent=
ed.</div><div><br></div><div>I know this particular text has been discussed=
 over and over again so I hate to revisit it. But based on the aforemention=
ed scenario I think maybe it still doesn&#39;t quite hit the mark. Access t=
oken injection is prevented. The token leakage scenarios mentioned in that =
section are all avoided. And while I know sender-constrained is recommended=
 elsewhere in the draft, it&#39;s not really a realistic option for the maj=
ority of deployments. <br></div></div>

<br>
<i style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:ba=
seline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-=
ui,-apple-system,system-ui,&quot;Segoe UI&quot;,Roboto,Oxygen-Sans,Ubuntu,C=
antarell,&quot;Helvetica Neue&quot;,Arial,sans-serif;color:rgb(85,85,85)"><=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Roboto,Oxygen-Sans,Ub=
untu,Cantarell,&quot;Helvetica Neue&quot;,Arial,sans-serif;font-weight:600"=
><font size=3D"2">CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.</font></span></i>
--000000000000db4f1a059ab42770--