Openid nonce replay attack in auth code flow
Looking at this question Openid connect nonce replay attack and the answer by @benbotto. I understand the replay attack in implicit flow but unable to understand it for auth code flow. Let's say an attacker intercepts the authentication response. The attacker could then paste the response (the 302 location) into their URL bar and get your client application to make a token request. Now this request made by the client application is a server-to-server request being made using the back channel (basically it doesn't involve the user agent/browser to exchange the authorization code).
@benbotto said: "when the authorization server responds, your client application can verify the nonce in the ID token against something that your server has tied to your user's user agent (e.g. a cryptographically random value that's stored in an HTTP-only cookie)"
My question is in this case what value does the client hash, to be passed in as nonce parameter which then the Auth server would include as claims in id_token. Assuming the replay request comes in without a cookie as the attacker doesn't know the secret nonce set in the user's(victim) browser, shouldn't the request be outright rejected by the client app and not even trigger the token request?
Why is the client app tricked into requesting the token to exchange the auth code when there is no cookie(nonce) in the replayed request?
This brings me to the question are replay attacks on the client application even possible in auth code flow?
