OAuth2.0について勉強しております。

ずばり、認可コードが必要な理由がわかりません。
アクセストークンを直接渡してはダメなのでしょうか？

OAuth2.0の仕組みは複雑のため、基本的な点を説明します。
私も理解が追い付いてなく説明が曖昧な点がありますがご容赦願います。

>アクセストークンを直接渡してはダメなのでしょうか？
アクセストークンを直接渡すのは、インプリシットフローという方法です。
現在は安全性の面で非推奨となっております。

もし認可コードがない場合、アクセストークンはURLのパラメータに付与されます。
そして、利用者のブラウザを経由してアプリに引き渡されることになります。
その場合、以下のような問題が考えられます。
・URLのパラメータに機密情報を設定するのはよろしくない
・利用者とアプリ間で通信を盗聴されている可能性ある

認可コードを挟むことによってこの問題は解決されます。
認可コードは短命のため万一漏れても問題はないです。
アクセストークンはアプリが直接、認可コードを認可サーバへ渡して
入手します。
これにより盗聴などの危険性もなくなり、安全にアクセストークンの受け渡しが
できます。

OAuth2.0は以上のような基本的な動作に加え、セキュリティ対策として
・state CSRF対策
・nonce なりすまし対策
・PKCE 認可コードの横取り対策
といった拡張機能も存在しており、かなり複雑になっています。

ご回答感謝します。

>もし認可コードがない場合、アクセストークンはURLのパラメータに付与されます。

この時点で認可サーバからアプリへ直接アクセストークンを付与しないのはなぜですか？

直接渡してしまえば盗聴リスクまで無いと考えています。
認可コードというプロセスを挟む理由が理解できておりません。

>この時点で認可サーバからアプリへ直接アクセストークンを付与しないのはなぜですか？
認可サーバからアプリへは通信は開始できません。そのため直接アクセストークンを
渡せません。
もし認可サーバからアプリへ通信するとなると、相手先のアプリが本物かどうか確認する
手段が必要になります。しかし、そのような手段は存在しません。

アプリから認可サーバへは通信は開始できます。その際に事前に貰っていた認可コードを
渡すことで、このアプリからの要求が本物であることが証明されます。

認可サーバがアプリへ認可コードを渡すためには、HTTPのリダイレクトの機能を利用し、
[認可サーバ -> ユーザのブラウザ -> アプリ]というようにユーザのブラウザを経由する
必要があります。この時に盗聴などの危険性があるということになります。

＞認可サーバからアプリへは通信は開始できません。そのため直接アクセストークンを
渡せません。

認可サーバからアプリへ通信を開始しなくても、
その直前にアプリから認可サーバに対して認可要求を送信しますよね。
もしかして、その認可要求はリダイレクトのため、アプリ→認可サーバの通信ではなく、利用者→認可サーバという通信なのでしょうか？

No.6 の書込みは私ではなく、スレ主様のものです。
掲示板の不具合により、書き込み者が変わってしまっているようです。

>もしかして、その認可要求はリダイレクトのため、アプリ→認可サーバの
>通信ではなく、利用者→認可サーバという通信なのでしょうか？
はい。最初の認可コードを入手するまでは利用者が仲介しているため、
利用者->認可サーバになります。

認可コードを入手したのちは、利用者は認可コードをアプリに渡し、
アプリ->認可サーバの通信が開始されます。

一般のSCの参考書では、OAuth2.0の概要のみで細かい動作については
解説がないと思われます。OAuth2.0の細かい動作については以下のような
書籍を参考にしてください。
・「認証と認可 Keycloak入門
    OAuth/OpenID Connectに準拠したAPI認可とシングルサインオンの実現」
・「OAuth徹底入門 セキュアな認可システムを適用するための原則と実践」

丁寧にご説明いただきありがとうございます。
理解できました。
またご紹介いただいた書籍は早速購入しようと思います。