> > 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.
This is true as long as the client actually validates the ID token it obtained at the token endpoint, even though it may have already obtained one from the authorization response. (e.g. response_type=code+id_token). It feels like this should be explained in a little more detail, since having to validate two ID tokens to protect against this attack is not necessarily obvious. Aaron ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Mon, Apr 6, 2020 at 12:09 AM Daniel Fett <f...@danielfett.de> wrote: > 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
