https://www.sc-siken.com/pdf/05_haru/pm2_2.pdf
解答は検証コードのSHAー256によるハッシュ値をbase64urlエンコードしたした値とチャレンジコードの値の一致ということで、
おそらくフローの（３）のチャレンジコードの送信はハッシュ値をエンコードした値で、
（７）の検証コードは平文ということが、読み取れると思いますが、
ではなぜ検証コードは最初からエンコードしないのでしょうか？普通に検証コード送る際もあらかじめハッシュ化してエンコードしておけば、一致の確認する際にはただ単に、両者の一致を確認すれば済むのに。。。って疑問です。

>普通に検証コード送る際もあらかじめハッシュ化してエンコードしておけば、一致の
>確認する際にはただ単に、両者の一致を確認すれば済むのに
チャレンジコードと検証コードを同じものを送らないのは、攻撃者に何らかの
手段で、認可コードを横取りされチャレンジコードも盗まれてしまうと、
トークンリクエストで認可コードと検証コード(チャレンジコードと同じ)が
送られてアクセストークンが取得されてしまうからだと思います。
検証コードをハッシュ化→エンコードしてチャレンジコードとすれば
チャレンジコードがもし盗まれても原像計算困難性で検証コードを求めるのは
困難なため、アクセストークンが取得されることを防げると思います。

wrinklyさん
ハッシュ化してエンコードされたチャレンジコードが盗まれると、検証コードでもそのまま盗んだ値を送ってしまうPass the Hash攻撃のようなことが起きてしまう。だから検証コードではあえて検証コードはハッシュ化せずそのままを送る必要があるのですね。今理解できました。
ありがとうございます！