After thinking about this a bit more, I think Brian's proposal makes sense. Reading closely, it actually makes the advice stronger. Sender-constrained tokens are a SHOULD somewhere else, so that still applies. I will adopt the wording into the BCP (unless I hear protests).
-Daniel Am 09.01.20 um 23:37 schrieb Brian Campbell: > The scenario I described in the beginning of this thread > (response_type=token+id_token and response_mode=form_post) started out > a bit more humbly as a way to facilitate a simple and efficient > cross-domain sign-on with id_token response type and form_post > response mode. Somewhat analogous to SAML SSO using the POST binding. > All the transactional data flows through the browser in the front > channel so no additional calls from the client/RP to the AS/OP are > needed. And no short-lived-transactional data has to be shared amongst > AS nodes (or between geographic locations). There are some nice > aspects to front channel flows. > > Then along came the desire to have the ability to periodically refresh > the user attributes associated with the session created off of SSO at > the client/RP so as to have fresh data on which to base access control > decisions. That was done by adding an access token into the mix, hence > the response_type=token+id_token with response_mode=form_post, and the > RP using it to periodically call the user info endpoint. Of course > this isn't the same as an ID-token-only-front-channel SSO but it still > retains some of the same benefits being a mostly front channel flow. > > I don't know how niche these cases are or even how often they are > actually put into use in actual deployments. But the token+id_token > and form_post flow was fresh in my mind for unrelated reasons when I > was re-reviewing the security BCP draft, which made me think again > about the SHOULD NOT wording in Section 3.1.2. And that led me to this > thread and my proposed text that would let the SHOULD for using > sender-constrained access tokens stand on its own and adjust the > qualification on the SHOULD NOT for implicit style access tokens to > focus on the issues that are particular to those flows. This doesn't > actually change the underlying meaning of the draft because > sender-constrained access tokens are still a SHOULD. But I think it > would make the draft more cohesive in terms of where and why certain > recommendations are made. > > > > > > > > On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle > <[email protected] <mailto:[email protected]>> wrote: > > Brian and others with similar use cases (Filip?): > > > > The current text does not prohibit your approach, provided you’ve > done the due diligence required by BCP 14 to go against a SHOULD > NOT. Could you provide more detail on the scenarios where you have > opted to use these implicit-based solutions? Is it impractical or > infeasible to use an authorization code-based approach in these > scenarios? If this is a particularly niche use case, then it may > not be worth including in the BCP (that’s basically what SHOULD > NOT is for). But if it’s more broadly applicable, then it may be > worth tweaking the “unless…” clause of that paragraph. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth <[email protected] > <mailto:[email protected]>> on behalf of Mike Jones > <[email protected] > <mailto:[email protected]>> > *Date: *Saturday, December 28, 2019 at 9:47 AM > *To: *Brian Campbell <[email protected] > <mailto:[email protected]>>, Torsten Lodderstedt > <[email protected] > <mailto:[email protected]>> > *Cc: *oauth <[email protected] <mailto:[email protected]>> > *Subject: *Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC > response types + form_post response mode > > > > I agree with Brian's suggested text changes. > > -- Mike > > ------------------------------------------------------------------------ > > *From:*Brian Campbell <[email protected] > <mailto:[email protected]>> > *Sent:* Saturday, December 28, 2019 5:33:24 AM > *To:* Torsten Lodderstedt > <[email protected] > <mailto:[email protected]>> > *Cc:* Mike Jones <[email protected] > <mailto:[email protected]>>; oauth <[email protected] > <mailto:[email protected]>> > *Subject:* Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC > response types + form_post response mode > > > > The requirement for replay/injection prevention at resource > servers is still there in section 3.2. This change only drops it > as a specific qualification on that SHOULD NOT for flows that send > access tokens in the authorization response. And instead focuses > that qualification on the additional risks that come with sending > access tokens in the authorization response. To me, this feels > more consistent. > > > > Looking again at section 3, I'd suggest also moving the fourth > paragraph of section 3.1.2 into section 3.2 so that the > description of sender-constrained is in the subsection that is > about sender-constraining. > > > > On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt > <[email protected] > <mailto:[email protected]>> wrote: > > 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] > <mailto:[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 > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=3fCGjTOAD43xXLzFaw3d6VC1kY43QvBfzNwdNfDckE0%3D&reserved=0>, > 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] > <mailto:[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] > <mailto:[email protected]>>: > > I agree with Brian. Please update the text to > describe this already safe usage. > > -- Mike > > > ------------------------------------------------------------------------ > > *From:*OAuth <[email protected] > <mailto:[email protected]>> on behalf of > Brian Campbell > <[email protected] > <mailto:[email protected]>> > *Sent:* Friday, December 27, 2019 11:03:30 AM > *To:* oauth <[email protected] <mailto:[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%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342106891&sdata=qO6%2BY%2FMoef0lyx4HwNLV8ID5DguAe3XjCQyxtvoFrPo%3D&reserved=0> > > > */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./* > > > */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./* > > > /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
