On Apr 5, 2020, at 12:42 PM, Aaron Parecki <[email protected]> wrote: > 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.
With PKCE, the client sends a challenge value to the authorization endpoint and a verifier value to the token endpoint. The authorization server will thus be able to correlate the request and response were made by the same client instance, and reject issuing tokens if there is an issue. With OIDC nonce, the client sends a nonce value to the auth endpoint and _receives_ that nonce back inside the id_token. The client can verify that the response corresponds to the request it made and reject requesting/using tokens if there is an issue. The first solution will almost inarguably lead to better implementations, as the single AS is taking responsibility for verification before issuing tokens, vs relying on potentially many client instances to do proper verification. But both do solve the problem. The problem I have with this choice is that a client library will not necessarily know PKCE is being honored vs ignored by the AS. So a client would need to always do _both_ to be a good citizen in some cases. So I would prefer that clients and servers MUST support PKCE, but servers MAY also allow nonce usage for security in the case of non-compliant clients (with appropriately vetted conformance to OIDC). > In any case, this section could benefit from some more explicit instructions > on how exactly to prevent authorization code injection attacks. Indeed. -DW _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
