機密のバックエンドクライアントを備えたモバイルアプリ用のOAuth2（PKCEが必要ですか？）
rfc6749もrfc8252もモバイルアプリのケースを考慮していないように見えるのはなぜですか？ しない保護されたリソース要求を作成します（したがってクライアントではありません）代わりに、バックエンドサーバー（機密クライアント）に依存します。
*ネイティブアプリの代わりにモバイルアプリという用語を使用していることに注意してください仕様ではネイティブアプリがパブリッククライアントとして定義されているため、
からrfc6749
セクション2.1：
ネイティブアプリケーションは、リソース所有者が使用するデバイスにインストールおよび実行されるパブリッククライアントです。リソースの所有者はプロトコルデータと資格情報にアクセスできます。アプリケーションに含まれるすべてのクライアント認証資格情報を抽出できることを前提としています。一方、アクセストークンや更新トークンなどの動的に発行される資格情報は、許容レベルの保護を受けることができます。少なくとも、これらの資格情報は、アプリケーションが相互作用する可能性のある悪意のあるサーバーから保護されます。一部のプラットフォームでは、これらの資格情報が同じデバイス上にある他のアプリケーションから保護されている場合があります。
セクション1.1：
client-リソース所有者に代わって、その承認を得て、保護されたリソース要求を行うアプリケーション
私が問い合わせているケースはrfc6749セクション2.1がweb applicationを定義する方法に似ていますが、HTMLユーザーインターフェイスの代わりに、インターフェイスはモバイルアプリになります。
Webアプリケーションは、Webサーバーで実行される機密クライアントです。リソース所有者は、リソース所有者が使用するデバイスのユーザーエージェントにレンダリングされたHTMLユーザーインターフェイスを介してクライアントにアクセスします。クライアントの資格情報とクライアントに発行されたすべてのアクセストークンはWebサーバーに保存され、リソースの所有者には公開されず、アクセスもできません。
rfc8252のネイティブアプリの定義は、パブリッククライアントであるアプリへの使用を制限しないため、より合理的に見えます。
"native app"ブラウザーコンテキストでのみ実行されるWebアプリとは異なり、ユーザーがデバイスにインストールするアプリまたはアプリケーション。ウェブベースのテクノロジーを使用して実装されているが、ネイティブアプリとして配布されるアプリ、いわゆる「ハイブリッドアプリ」は、この仕様ではネイティブアプリと同等と見なされます。
ただし、仕様はネイティブアプリも（パブリック）クライアントである場合にのみベストプラクティスを提供します。
要約すれば、
- 上で説明したクライアントプロファイル（仕様または他の場所）についての言及が見つからなかったのはなぜですか。
- 悪意のあるアプリが承認コードを傍受した場合でも（外部ユーザーエージェントからアプリ間通信を介してネイティブアプリに送信される）、承認コードの付与（PKCEなし）は十分に安全であると見なされますか？バックエンドに保存されているクライアントシークレットを所有していないため、アクセストークンと交換できませんか？
これらの質問をするのは理論をよりよく理解するためであり、実用的なものではないことに注意してください。
説明するフローは、Googleがモバイルアプリに提供するものとまったく同じです。 https://developers.google.com/identity/protocols/CrossClientAuth
Rfc 6749をさらに詳しく見てみると、このフローは推奨事項を順守していないことがわかります。
https://tools.ietf.org/html/rfc6749#section-4.1.
認可サーバーは、
o認証された機密クライアントに認証コードが発行されていることを確認します。または、クライアントが公開されている場合は、リクエストの「client_id」にコードが発行されていることを確認します。
実際、認証コードはネイティブアプリに発行され、コードを交換しようとするのはWebアプリケーションです。
RFCを厳密に尊重するかどうかを決定するのは開発者の責任であり、この場合はPKCEでフロー認証コードを使用してから、リソースサーバーにアクセスできるようにアクセストークンをバックエンドサーバーに送信します。または、彼がグーグルと同じフローを使用したい場合。