c_hash (Code Hash) Claim in an ID Token

The computation matches at_hash exactly, only the input differs: the ASCII octets of the authorization code rather than the access token. Same rule for choosing the hash from the ID token's alg, same truncation to the left half of the digest, same base64url encoding without padding. A relying party that already implements one gets the other for a couple of lines.

Hybrid flows are the reason it exists. In the code id_token response type the browser receives the ID token and the code together in the front channel, where both are exposed to whatever else is running there. Without c_hash an attacker could keep the honest ID token and swap in a code obtained elsewhere, so that the relying party ends up holding tokens for a different account than the one it just authenticated.

The relying party therefore recomputes the hash from the code it received before redeeming it. If the values differ the response was tampered with and the exchange must not happen. This is one of the few checks that has to run early, since the point is to catch the substitution before the code is spent at the token endpoint.

Financial grade profiles add a matching s_hash claim over the state parameter for the same reason, so a deployment carrying c_hash may carry that as well. The decoder treats both the same way: they appear under Custom claims with their raw values, since only the seven RFC 7519 claims get an explanation, and neither can be checked without the value that was hashed.