【入門編】 OAuth 2.0におけるPKCE(Proof Key for Code Exchange)の仕組み – Web APIアーキテクチャ・データ連携実践ガイド

鍵を渡す前に「合言葉」を決めよう！OAuth 2.0 PKCEが守る認可の鉄則

こんにちは！ネットワークの世界にどっぷり浸かっているインフラアーキテクトです。

普段、私たちが何気なく使っている「Googleアカウントでログイン」のような機能。裏側ではOAuth 2.0という仕組みが動いているのですが、今日はその中でも、現代のアプリ開発には欠かせない「PKCE（ピクシー）」というセキュリティ技術についてお話しします。

「小難しい名前だな…」と感じたあなた、安心してください。今日は郵便配達の仕組みに例えて、パケットが飛び交う裏側を優しく紐解いていきましょう！

—

そもそも、なぜ「PKCE」が必要なの？

昔ながらのOAuth 2.0フローでは、認可サーバーから「認可コード」という通行証をもらい、それをサーバーに渡して「アクセストークン（本物の鍵）」をもらう、という手順を踏みます。

しかし、スマホアプリのように「誰でも中身を見られる場所」で動くプログラムだと、この通行証を悪いやつに盗み見られるリスクがあるんです。

例えるなら、「手紙（通行証）をポストに入れた瞬間に、誰かに盗まれる」ようなもの。これでは困りますよね。そこで登場したのが、PKCE（Proof Key for Code Exchange）です。

—

郵便配達で例える「PKCE」の魔法

PKCEの考え方は、いたってシンプルです。「手紙を渡す前に、あらかじめ秘密の合言葉を登録しておく」のです。

1. 準備（コードベリファイア作成）：
アプリ側で、自分だけが知っている「秘密の合言葉（コードベリファイア）」を作ります。
2. 封印（コードチャレンジ作成）：
その合言葉をこっそり加工して「暗号化されたヒント（コードチャレンジ）」を作ります。
3. 申請：
認可サーバーに「ログインしたいです！このヒント（コードチャレンジ）を預かってください！」と伝えます。
4. 照合：
後で通行証（認可コード）を持っていくときに、「実はこのヒントの元になった合言葉（コードベリファイア）はこれです！」と提示します。

認可サーバーは「なるほど、ヒントと合言葉が一致するね。君は間違いなく本人だ！」と認め、初めて鍵を渡してくれるのです。これなら、もし途中で通行証を盗まれても、悪いやつは「合言葉」を知らないので、鍵をもらうことはできません。

—

実装のイメージ：Pythonで「合言葉」を作ってみよう

PKCEの仕組みを具体的にどうコードにするか、Pythonの例で見てみましょう。

import hashlib
import base64
import os

# 1. 秘密の合言葉（コードベリファイア）を生成
# 43〜128文字のランダムな文字列を用意します
code_verifier = base64.urlsafe_b64encode(os.urandom(32)).decode('utf-8').replace('=', '')

# 2. 合言葉をハッシュ化して「コードチャレンジ」を作成
# SHA-256という手法で暗号化のような加工を施します
code_challenge = base64.urlsafe_b64encode(
    hashlib.sha256(code_verifier.encode('utf-8')).digest()
).decode('utf-8').replace('=', '')

print(f"秘密の合言葉: {code_verifier}")
print(f"サーバーに送るヒント: {code_challenge}")

この code_challenge を認可リクエストのURLパラメータに含めるだけで、セキュリティは劇的に向上します。

—

ネットワークエンジニアの視点：裏側のパケットはどうなっている？

私たちが普段見ているWeb画面の裏側では、HTTP GET リクエストが飛び交っています。

例えば、認可サーバーへリクエストを送る際、ブラウザのURLバーにはこんな感じのパラメータが乗っかっています。

https://auth.example.com/authorize?
  response_type=code&
  client_id=my-app-id&
  redirect_uri=https://myapp.com/callback&
  code_challenge=xyz123abc...&  <-- これがPKCEのヒント！
  code_challenge_method=S256

このパケットがインターネットという荒波を越えてサーバーに届くとき、ネットワーク機器はこれをただの文字列として運びますが、認可サーバーにとっては「あ、このリクエストにはPKCEが付いているな。よし、合言葉の照合準備をしよう」という重要なシグナルになるのです。

—

まとめ：セキュリティは「疑うこと」から始まる

ネットワークやAPIの世界では、「通信相手が本当に本人か？」を疑うことがすべての始まりです。PKCEは、その疑いを「数学的な合言葉」で晴らすための、とても美しく賢いプロトコルです。

認可コードを盗まれても大丈夫： 合言葉がないと使えないから。
実装は難しくない： ライブラリが勝手に計算してくれることも多い。
今や標準： スマホアプリやSPA（シングルページアプリケーション）では必須の作法。

もしあなたがこれからAPI連携を開発するなら、ぜひ「PKCE、使ってる？」と自分に問いかけてみてください。その一歩が、あなたの作ったサービスを、そしてユーザーのデータを守る堅牢な壁になります。

分からないことがあれば、いつでもまた聞きに来てくださいね。ネットワークの深淵で、いつでもお待ちしています！