Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

PKCE(ピーケイシーイー)とは | 意味や読み方など丁寧でわかりやすい用語解説

PKCE(ピーケイシーイー)の意味や読み方など、初心者にもわかりやすいように丁寧に解説しています。

作成日: 更新日:

読み方

日本語表記

ピーケーシーイー (ピーケーシーイー)

英語表記

PKCE (ピーケーシーイー)

用語解説

PKCEは、Proof Key for Code Exchangeの略であり、主にOAuth 2.0のセキュリティを強化するために設計された拡張機能である。特にシングルページアプリケーション(SPA)やモバイルアプリケーションといった、クライアントシークレットを安全に保管できない「パブリッククライアント」と呼ばれる種類のアプリケーションにおいて、認可コード横取り攻撃(Authorization Code Interception Attack)を防ぐことを目的としている。これにより、攻撃者が認可コードを不正に取得しても、そのコードを使ってアクセストークンを交換することを阻止できるようになる。PKCEは、OAuth 2.0の認可コードフローにおいて、クライアントと認可サーバーの間で追加の検証を行うことで、このセキュリティ課題を解決する。

OAuth 2.0は、ユーザーがパスワードなどの認証情報をクライアントアプリケーションに直接渡すことなく、別のサービス(認可サーバー)にあるリソース(例:写真、プロフィール情報)へのアクセスを許可する仕組みを提供する。その中でも、最も一般的に利用されるフローの一つが認可コードフローである。このフローでは、クライアントアプリケーションがユーザーを認可サーバーへリダイレクトし、ユーザーがログインと認可を行うと、認可サーバーはクライアントへ「認可コード」を発行する。クライアントはこの認可コードをバックエンドサーバーに送り、クライアントシークレットと共にトークンエンドポイントに提示することで、アクセストークンと交換する。しかし、SPAやモバイルアプリのようなパブリッククライアントでは、その性質上、クライアントシークレットをソースコードやアプリケーションバイナリ内に埋め込む必要があり、これはセキュリティ上のリスクとなる。攻撃者がクライアントシークレットを抽出してしまえば、たとえ認可コードが傍受されても、それを使ってアクセストークンを取得できてしまう可能性がある。さらに、たとえクライアントシークレットがなくても、認可コード自体がリダイレクトURI経由で傍受され、攻撃者がそのコードを使ってアクセストークンを取得できてしまう「認可コード横取り攻撃」という脆弱性が存在した。攻撃者が不正なリダイレクトURIを登録したり、ユーザーをだまして不正なリダイレクトURIに認可コードを送らせたりすることで、認可コードを奪い取ることが可能になる。この問題は、特にモバイルアプリがカスタムURLスキームを使用する場合や、SPAが異なるタブで動作する場合に顕著となる。

PKCEはこの認可コード横取り攻撃を防ぐために導入された。そのメカニズムは以下の通りである。まず、クライアントアプリケーションは、認可リクエストを発行する前に、あるランダムな文字列「code_verifier(コード検証器)」を生成する。このcode_verifierは非常に長いランダムな文字列で、推測困難な値である必要がある。次に、クライアントはこのcode_verifierを特定の変換アルゴリズム(通常はSHA256ハッシュ関数とBase64 URLエンコーディング)を使ってハッシュ化し、「code_challenge(コードチャレンジ)」を生成する。そして、クライアントはユーザーを認可サーバーへリダイレクトする際に、通常の認可リクエストパラメータに加えて、このcode_challengeと、どの変換アルゴリズムを使ったかを示す「code_challenge_method」を認可サーバーに送信する。

認可サーバーは、このcode_challengecode_challenge_methodを一時的に保存する。ユーザーが認可を承認すると、認可サーバーは通常の認可コードをクライアントアプリケーションに発行し、指定されたリダイレクトURIに送り返す。この時点では、認可コードが傍受されたとしても、攻撃者はまだアクセストークンを取得することはできない。

クライアントアプリケーションは、受け取った認可コードを使ってアクセストークンを取得するため、認可サーバーのトークンエンドポイントにトークンリクエストを送信する。この際、クライアントは受け取った認可コードと共に、最初に自身で生成して保存しておいたcode_verifierをトークンリクエストに含めて送信する。

認可サーバーは、このトークンリクエストを受け取ると、クライアントから送られてきたcode_verifierを、以前保存しておいたcode_challenge_methodで指定されたアルゴリズムを用いてハッシュ化し、新しいcode_challengeを生成する。そして、この新しく生成したcode_challengeが、最初に認可リクエスト時にクライアントから受け取って保存しておいたcode_challengeと一致するかどうかを検証する。この検証が成功した場合にのみ、認可サーバーはアクセストークンをクライアントに発行する。もし検証が失敗した場合、つまりcode_verifierが正しくない場合、認可サーバーはアクセストークンの発行を拒否する。

このPKCEの仕組みにより、たとえ攻撃者が認可コードを傍受したとしても、トークン交換に必要なcode_verifierを知らない限り、アクセストークンを取得することが不可能になる。code_verifierはクライアントと認可サーバーの間で直接やり取りされる情報であり、リダイレクトURIやブラウザのURLを通じて公開されることはないため、攻撃者がこれを知ることは非常に困難である。このようにPKCEは、クライアントシークレットを使用できないパブリッククライアントのセキュリティを大幅に向上させる。また、機密クライアント(サーバーサイドアプリケーションなど、クライアントシークレットを安全に保管できるアプリケーション)においても、追加のセキュリティレイヤーとしてPKCEを使用することが推奨されている。PKCEはIETF RFC 7636として標準化されており、現代のOAuth 2.0およびOpenID Connectの実装において、特にパブリッククライアントを使用する場合には事実上必須のセキュリティ機能となっている。これにより、開発者はより安全なアプリケーションを構築し、ユーザーはより安心してサービスを利用できるようになった。

関連コンテンツ