Hi Aaron, Thanks for your feedback!
Am 05.04.20 um 20:42 schrieb Aaron Parecki: > Section 2.1.1 says: > > Clients MUST prevent injection (replay) of authorization codes into > the authorization response by attackers. The use of PKCE [RFC7636] > is RECOMMENDED to this end. The OpenID Connect "nonce" > parameter and > ID Token Claim [OpenID] MAY be used as well. > > > Minor nit: this should be "ID Token claim" with a lowercase "c". I > spent a while trying to figure out what an "ID Token Claim" is before > realizing this sentence was referring to the "nonce" claim in an ID Token. Upper case "Claim" follows the convention in OIDC Core, which says for example, "these additional requirements for the following ID Token Claims apply". To keep the documents consistent, I will change the sentence above to "The OpenID Connect "nonce" parameter and the respective Claim in the ID Token [OpenID] MAY be used as well." > > Aside from that, I'm struggling to understand what this section is > actually saying to do. Since this is in the "Authorization Code Grant" > section, is this saying that using response_type=code is fine as long > as the client checks the "nonce" in the ID Token obtained after it > uses the authorization code? It seems like that would still allow an > authorization code to be injected. I don't see how the "nonce" > parameter solves anything to do with the authorization code, it seems > like it only solves ID token injections via response_type=id_token. The injected authorization code would always refer to a different session (started with a different nonce). The client would therefore get an ID Token with a different nonce. The assumption is that the client would then throw away both the ID Token and the access token. Does that make sense? > > In any case, this section could benefit from some more explicit > instructions on how exactly to prevent authorization code injection > attacks. Indeed, we should add a sentence or two on that. -Daniel
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
