クライアントから認可サーバへチャレンジコードを送る時は、検証コードに対してsha256から得られたハッシュ値にbase64urlでエンコードしますよね。

クライアントから認可サーバへ検証コードを送る時は、なぜbase64urlでエンコードしないのですか？

検証コードは、決められた文字種を使った43～128文字のランダムな文字列と
RFC7636で規定されているようです。だから、わざわざbase64urlでエンコード
する必要がないのです。
RFC7636には、32バイトの乱数を生成し、base64urlエンコードで、43文字の
ランダムな文字列を生成する例が載っているそうです。だから、既に
base64urlエンコード済と言えるかもしれません。

上記は、全て
「認証と認可 Keycloak入門」
p192 に書いてあることの受け売りです。

ご回答ありがとうございます。
書籍の名前まだあげていただき、とても参考になります。

ちなみにOauthで一番気になるポイントとして、
この問題ではAuthorizationヘッダにBasic認証を行うためのクライアントIDおよびクライアントシークレットの情報を送っていますが、認可コードフローでは必ず行われるのでしょうか？
それともこのあたりのクライアント認証方式は実装によるものであって、認可コードフローでもBasic認証を行わないものもあるのでしょうか？

この投稿は投稿者により削除されました。(2024.03.30 14:34)

この投稿は投稿者により削除されました。(2024.03.30 19:16)

rfc7636では

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
4. Protocol
4.1. Client Creates a Code Verifier
「決められた文字種を使った43～128文字のランダムな文字列」を作るときに、
オクテットによる乱数生成器（例えば、/dev/urandomをcatした場合に出てくるものを想像してみてください。出てくるのはバイナリなので、実際には、odやxddでダンプしないとまともに使えないのです。）をBase64urlEncodeしたものなので、実際にはすでにエンコードされたのを使っていることになります。

ABNFの
のALPHAやDIGITは一見するとあれBASE64みたいな書き方か？と思いそうですが、ABNFでASCIIの大文字と小文字 (A-Z a-z)と十進数字 (0-9)はそう書くので、エンコードはこの場（Code-Verifier作成）においては発生していません。その手前で用意するときのBASE64は、乱数生成器をSHOULD通りに使うときに必要になる、といっていいと思います。

ご回答ありがとうございます。とても勉強になります。