PKCEとクライアントシークレット
静的に提供されるWebアプリクライアントを開発している場合は、暗黙の許可フロー（これはお勧めできません）を使用するか、PKCEで承認コード許可フローを使用する必要があります。サーバーによって動的に提供されるWebアプリクライアントを開発しているとすると、PKCEを使用せずにOAuth 2.0で認証コード付与フローを利用することができます-コールバックと後続のトークン要求はサーバー側で処理され、クライアントシークレットをサーバーに安全に保存できます。
ただし、この場合でもPKCEを使用することは可能です（サーバーはクライアントアプリの代わりに必要なコード検証を生成できます）。したがって、私の質問は、1つのアプローチを他のアプローチよりも使用することには利点がありますか（クライアントシークレットを提供するか、PKCEを使用するか）。このコンテキストでは、1つは他よりも安全ですか？
つまり、認証コードが漏洩する可能性があるかどうかです。
PKCEは、漏洩した「認証コード」が役に立たないようにすることを目的としています。認証コードを要求すると、PKCEはnonceのハッシュを送信するように要求します。コードを利用するときは、元のナンスを提供する必要があります。
つまり、認証コードのリクエストとレスポンスを監視する悪意のあるアクター（XSSまたはCSRFの脆弱性）は、ナンスを知らないため、コードを引き換えることができません。
編集：さらに、client_secretは、サーバーのみが認証コードを引き換えることができることを意味します。しかし、誰でもあなたのサーバーにメッセージを送ることができます！認証コードが漏洩した場合、それは誰がサーバーに認証コードを送信しているか分からないことを意味します-最初にそれを要求したのは本人ですか、それとも盗聴アプリですか？ nonceをチェックしないと、サーバーはclient_secretを使用して盗聴者の認証コードを引き換えることになります。