Am 27.12.19 um 23:27 schrieb Filip Skokan: > 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.
The encryption of JARM does not add much if the token leaks: An attacker could just inject it into a flow on his device. This is also why sender-constraining, even if it would be possible in the "token id_token" scenario, would not help at all. > > 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...) +1 -Daniel > > 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 >>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3..1...2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cee48992fa75642e2cbf908d78aff8d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637130702523877347&sdata=LJfYSigLXqZjLNl%2Bx1ycBSHJn6UKJFXhr5As1zb1g98%3D&reserved=0>, >>> 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
