I can confirm that this works on our use-case as of commit 5339799372d39eed5a356ee1b351cac0b576614f

Refactored AddAuthorizationCodeHashToIDToken to exploit newly added helper functions when calculating the c_hash value. The helper functions may be used together with the IDTokenManipulationStrategy profile configuration (see ) in order to include c_hash value to the id_token also when it's not mandated by the spec.

For instance the following script can be used for including c_hash in the token endpoint:

The script above can be wired to a OAUTH2.Token profile in the following way in relying-party.xml:

Note that this example only works in the token endpoint with authorization code grant. The id_token may also be produced via refresh tokens: in that case the c_hash value must be calculated in the similar way when the authorization code is around, and then stored into refresh tokens via mechanism implemented in .

The requirement from the customer comes probably from 16.11.  Token Substitution

Under those assumptions the c_hash might make sense in any scenario where the Authorization has gone thru a code

We’ll have a conversation about that with the customer in order to double check and will get back ASAP

It sounds logical to implement in a way that it offers a way for deployers to manipulate id_token claims openly. A custom code/function could be wired to add or remove claims to/from the id_token.

In the OIDC core spec, the c_hash claim is only mentioned under the section 3.3. Authentication using the Hybrid Flow. Over there, it’s specified that it’s required when id_token is issued from the authorization endpoint together with the authorization code. So, it clearly refers to hybrid flow only. In the sections for the authorization code flow and implicit flow (3.1 and 3.2), the claim c_hash is not mentioned at all.