PKCEは実際に何を保護していますか？
[〜＃〜] pkce [〜＃〜] がモバイルアプリでどのように機能するかを理解しようとしていますが、よくわからないことがあります。
だから私が集めることができるものから、クライアントアプリはコードベリファイアとして知られているランダムな暗号で安全な文字列を作成します。これは保存されます。これから、アプリはコードチャレンジを生成します。コードチャレンジは、APIリクエストでサーバーに送信されます。S256やプレーンなど、チャレンジの生成方法も一緒に送信されます。サーバーは、このチャレンジを、該当するリクエストの適切なauthorization_codeとともに保存します。
その後、クライアントがコードをアクセストークンと交換しようとすると、リクエストで元のコードベリファイアも送信します。次に、サーバーは保存されているチャレンジと、この特定のコード用に生成するために元々使用されていたメソッドを取得し、同等のs256 /プレーンハッシュを生成して比較します。一致する場合は、アクセストークンを返します。
私が得ていないのは、これがクライアントアプリのシークレットを置き換える方法です。確かにこれを偽装したい場合は、client_idを通常どおりに使用して独自のコードベリファイアとチャレンジを生成し、そもそもPKCEが必要ない場合と同じ立場になります。元のアイデアが基本的に「動的な秘密」であるという元のアイデアであった場合、PKCEは実際にここで解決しようとしていますか？私の仮定は、誰かがauth_codeが返されますが、SSLを再度使用している場合、これが必要ですか？公開アプリにシークレットを保存するべきではないという事実に代わるものとして請求されますが、サーバーではなくクライアントが生成を担当しているという事実は、実際にはサーバーでは役に立たないと感じています。
この write-up Okta がこのテーマについて持っていることは、これをかなりよく説明しています。
これは、PKCEがネイティブアプリケーション（Android、iOS、UWP、Electronなど）を対象としているためだと思います。アプリケーションのセキュリティコンテキストを離れ、ブラウザーにアクセスして認証を行い、アプリケーションからの安全な復帰に依存しています。ブラウザ。アプリケーションへのリダイレクトにTLSが必ずしも必要ではありません（カスタムスキームの場合、OSに依存してアプリケーションに応答を返します）。そのため、認証コードが悪意のある場所に移動した場合、受信アプリは、動的シークレットがないとアクセストークンを取得できません。
パブリッククライアントの動的シークレットのメリットはここで明白です。PKCEの前提は、ブラウザからアプリケーションへの応答を傍受することは難しくないということです。
PKCEが重要な理由は、モバイルOSでは、OSがアプリに登録してリダイレクトURIを処理できるため、悪意のあるアプリが正当なアプリの認証コードを使用してリダイレクトを登録および受信できるためです。これは、認証コード傍受攻撃として知られています。
Authorization Code Interception Attack
これはWSO2によってここに記述されています：
特定のリダイレクトURIのハンドラーとして複数のアプリケーションを登録できるため、このフローの脆弱性は、悪意のあるクライアントが正当なアプリケーションが処理する同じURIスキームのハンドラーとしてそれ自体を登録する可能性があることです。これが発生した場合、オペレーティングシステムが悪意のあるクライアントへのURIを解析する可能性があります。この攻撃の流れを次の図に示します。
Androidなどの一部のオペレーティングシステムでは、フローのステップ5で、「完全なアクションの使用」アクティビティを使用して解析される前に、リダイレクトURIを処理するアプリケーションを選択するように求められます。これにより、ユーザーは正当なアプリケーションを識別して選択できるため、悪意のあるアプリケーションによる処理を回避できます。ただし、一部のオペレーティングシステム（iOSなど）にはそのようなスキームがありません。
これをよりよく理解するために、OpenIDの図と説明を以下に示します。モバイルシステムブラウザーがリダイレクトURIを受信して正しいアプリにルーティングする責任があることがわかります。
ただし、モバイルOSでは多くのアプリが同じリダイレクトURIに登録できるため、悪意のあるアプリが次の図に示すように、正当な認証コードに登録して受信する可能性があります。これもWSO2によるものです。
PKCEによる攻撃の軽減
PKCEは、OAuth 2.0要求（認証コードの要求）を開始するアプリと、トークンの認証コードを交換するアプリとの間で共有される知識を要求することにより、これを軽減します。認証コード傍受攻撃の場合、悪意のあるアプリには、トークン交換を完了するためのベリファイアがありません。