Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent.
> Am 28.12.2019 um 00:02 schrieb Brian Campbell > <[email protected]>: > > > I'm not suggesting that it should be a recommended flow. But recommending > against it, as the text does now, seems overreaching and unnecessary. I know > *consensus* was previously found on the text in -13 but best I can recall > that discussion was mostly around Nat advocating to allow room for some > future self-issued IDP type case and the conversation kind of got hung up on > that. > > Here's some proposed text, which I think still largely captures the intent of > the BCP while not explicitly recommending against legitimate cases like the > one I brought here or Nat's or something like JARM. > > In order to avoid these issues, clients SHOULD NOT use the implicit > grant (response type "token") or other response types issuing > access tokens in the authorization response, unless access token injection > in the authorization response is prevented and the aforementioned token > leakage > vectors are mitigated. > > The draft already recommends sender-constrained access tokens elsewhere in > the document. It doesn't need to be repeated as a qualifying condition around > this SHOULD NOT. > > I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is > evident from several attempts at bringing/doing related work here) but I do > worry that the recommendation in the draft is sufficiently unachievable to > the vast majority that it might undermine the credibility of the document. > But I get the aspirational aspect of it and, other than some suggested > tweaks, am resigned to see it stay in the document. But let's let that > recommendation stand on its own in the document and not also tie it to other > considerations. > > >> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt >> <[email protected]> wrote: >> 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 > > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
