Encrypted JARM responses are in a very similar position. Access Token value is not part of the URL and the response itself is protected. Such response is usually only consumed by a server side application. Same as any form_post response.
We could go into further clarifying the client application topology to enable these uses but i don’t think it’s worth it. Why make excuses to keep implicit issued access tokens around in when code flow is the way the WG has decided to go. (Here we go again...) Best, Filip > 27. 12. 2019 v 21:41, Torsten Lodderstedt > <[email protected]>: > > > As Brian said, we have discussed this several times and this text found > consensus. > > Using post reduces the attack surface but does not allow to bind the access > token to the legitimate client. We are recommending sender constrained access > tokens in the BCP. So recommending a flow that does not support sender > constrained access tokens is a contradiction. > > What do other WG members think? > >>> Am 27.12.2019 um 21:28 schrieb Mike Jones >>> <[email protected]>: >>> >> >> I agree with Brian. Please update the text to describe this already safe >> usage. >> >> -- Mike >> >> From: OAuth <[email protected]> on behalf of Brian Campbell >> <[email protected]> >> Sent: Friday, December 27, 2019 11:03:30 AM >> To: oauth <[email protected]> >> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + >> form_post response mode >> >> 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, 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. >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >> material for the sole use of the intended recipient(s). Any review, use, >> distribution or disclosure by others is strictly prohibited.. If you have >> received this communication in error, please notify the sender immediately >> by e-mail and delete the message and any file attachments from your >> computer. Thank you. >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
