境界の内側は、もう安全地帯ではない――OAuth 2.0 + PKCEで挑むZTNAクライアント認証の真実
ネットワークエンジニアとして長年、企業の要塞ネットワークを守ってきた私だが、近年のクラウドシフトとリモートワークの常態化によって、かつての「社内LAN＝安全」という神話が完全に崩れ去ったのを痛いほど目の当たりにしてきた。VPNゲートウェイの脆弱性を突かれたり、一度社内に入り込んだマルウェアがラテラルムーブメント（水平展開）で重要サーバーを蹂虙していく光景は、もうお腹いっぱいだ。
そこで私たちが直面しているのが、「境界防御からゼロトラストへのパラダイムシフト」である。
「信頼するな、常に検証せよ（Never trust, always verify）」。このゼロトラストアーキテクチャ（ZTA）の核心を具現化する技術の一つが、ZTNA（Zero Trust Network Access）だ。しかし、ここで一つ大きな疑問が生じる。「端末やユーザーが本当に正当なものか、どうやって厳密に証明するのか？」特に、スマートフォンやIoTデバイス、あるいはブラウザ上で動くシングルページアプリケーション（SPA）といった、秘密情報（クライアントシークレット）を安全に保持できないパブリッククライアントからのアクセスにおいて、従来の認証モデルはあまりにも無力だった。
今回は、この難題を鮮やかに解決し、パブリッククライアントからのZTNAアクセスにおけるセキュリティの金字塔となっている「OAuth 2.0 認可コードフロー + PKCE（Proof Key for Code Exchange）」について、現場の泥臭い知見と実装のリアルを交えて徹底解説しよう。
—
1. なぜ「秘密情報」を隠せないクライアントで認証が破綻するのか？
従来のOAuth 2.0では、バックエンドで動く信頼されたサーバー（コンフィデンシャルクライアント）を前提としていた。サーバー側には client_secret という、いわば「合言葉」を安全にハードコードや環境変数で隠蔽できたからだ。
だが、現代のZTNAが保護する対象は、カフェのWi-Fiから社内リソースにアクセスする営業マンのiPadであり、自宅の個人PCでコードを書くエンジニアのブラウザだ。これらはすべてパブリッククライアントに分類される。
パブリッククライアントの宿命：リバースエンジニアリングの脅威
モバイルアプリのバイナリを逆コンパイルしたり、ブラウザのデベロッパーツール（Networkタブ）を開けば、そこにハードコードされた client_secret やAPIエンドポイントは丸裸になる。もし攻撃者がこのシークレットを奪い取れば、いかに強固なID/パスワードであっても、正当なクライアントになりすまして社内システムへ侵入できてしまう。
「じゃあ、クライアントシークレットなんて使わなければいいじゃないか」
その通り。そこで登場するのが、シークレットの代わりに「動的に生成する使い捨ての暗号学的証明」を用いる PKCE（RFC 7635） なのだ。
—
2. 痛みを伴う歴史：なぜAuthorization Code FlowにPKCEが必須なのか？
元々、PKCEはネイティブアプリ（iOS/Android）における「認可コードインターセプト攻撃」を防ぐために考案された。しかし、現代のセキュリティ標準では、SPAを含めたすべてのパブリッククライアントにおいてPKCEの利用が必須（MUST）とされている。
ここで、裏側でパケットがどうやり取りされているのか、通信の全貌（シーケンス）を見てみよう。
[クライアント (SPA/Mobile)] [認可サーバー (IdP)] [リソースサーバー / ZTNA Gateway]
| | |
1. 乱数(Verifier)生成 & | |
ハッシュ(Challenge)算出 | |
| | |
2. 認可リクエスト送信 | |
(code_challenge, method=S256) --------> | |
| | |
3. ユーザー認証 (IdPでログイン) | |
<-------------------------------------------- | |
| | |
4. 認可コード返却 (Authorization Code) | |
<-------------------------------------------- | |
| | |
5. トークンリクエスト | |
(認可コード + 元の code_verifier) ------------> | |
| | (Verifierのハッシュ値と |
| | Challengeを比較して検証) |
| | |
6. アクセストークン発行 (Access Token) | |
<-------------------------------------------- | |
| | |
7. ZTNA保護リソースへアクセス (Bearer Token付与) ----------------------------------------->このフローの美しさは、ステップ2で「これから使う秘密の合言葉（code_verifier）のハッシュ値（code_challenge）」を先に宣言し、ステップ5で「本物の合言葉そのもの」を提示してサーバー側で答え合わせをする点にある。仮にステップ4の認可コードが途中で傍受されても、元の code_verifier を持っていなければ攻撃者はアクセストークンを手に入れられない。まさにゼロトラストの思想を体現した仕組みだ。
—
3. パラメーターの解剖学：実務で迷わないための必須知識
API設計やインフラのOAuthプロキシ（OAuth2-ProxyやKong、Envoyなど）を設定する際、以下のパラメーターの意味を正確に理解していないと、CORSエラーや invalid_grant の無限ループにハマることになる。現場でよく見る主要なパラメーターを整理しておこう。
| パラメーター名 | 役割・意味 | 実務上の注意点 |
| :— | :— | :— |
| response_type=code | 認可サーバーに「認可コードをくれ」と要求する。 | 以前のような token（インシデントの温床だった暗黙的フロー）は絶対に使わないこと。 |
| code_challenge | code_verifier をSHA-256でハッシュ化し、Base64URLエンコードしたもの。 | プレーンテキスト（plain）は中間者攻撃に脆弱なため、必ず code_challenge_method=S256 を指定する。 |
| code_verifier | クライアント側がランダムに生成する高エントロピーな文字列（43〜128文字）。 | セッションストレージ等に一時保存し、トークン交換時に一度だけ使用して即座に破棄する。 |
| redirect_uri | 認証完了後にユーザーを「連れ戻す」ためのコールバックURL。 | 厳密な完全一致（Exact Match）検証が必須。ワイルドカードの使用は脆弱性の元。 |
—
4. 実装ハンズオン：PythonとFetch APIによるPKCEフローの具現化
理屈はこれくらいにして、実際に手を動かしてみよう。ここでは、ZTNAクライアントやカスタムポータルを想定し、PKCEを用いた一連のプロセスをコードで表現する。
① クライアント側（JavaScript / Fetch API）での code_verifier と code_challenge の生成
ブラウザのWeb Crypto APIを使用すると、外部ライブラリに頼らずとも安全な暗号学的ハッシュを生成できる。
// ランダムな文字列（Verifier）を生成する関数
function generateCodeVerifier() {
const array = new Uint8Array(32);
window.crypto.getRandomValues(array);
// Base64URLエンコード
return btoa(String.fromCharCode.apply(null, array))
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=+$/, '');
}
// VerifierからS256のChallengeを計算する関数
async function generateCodeChallenge(verifier) {
const encoder = new TextEncoder();
const data = encoder.encode(verifier);
// SHA-256でハッシュ化
const digest = await window.crypto.subtle.digest('SHA-256', data);
// Base64URLエンコード
return btoa(String.fromCharCode.apply(null, new Uint8Array(digest)))
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=+$/, '');
}
// 実際のフロー開始時の処理
async function startAuthFlow() {
const verifier = generateCodeVerifier();
// 後続のトークン交換で使うため、sessionStorageに退避
sessionStorage.setItem('pkce_verifier', verifier);
const challenge = await generateCodeChallenge(verifier);
const authUrl = new URL('https://auth.ztna.enterprise.internal/oauth/authorize');
authUrl.searchParams.append('client_id', 'ztna-portal-client');
authUrl.searchParams.append('response_type', 'code');
authUrl.searchParams.append('redirect_uri', 'https://portal.ztna.enterprise.internal/callback');
authUrl.searchParams.append('code_challenge', challenge);
authUrl.searchParams.append('code_challenge_method', 'S256');
authUrl.searchParams.append('scope', 'openid profile ztna:access');
// 認可サーバーへリダイレクト
window.location.href = authUrl.toString();
}② バックエンド（Python / FastAPI）での認可コードと Verifier の検証・トークン取得
ユーザーが認証を終えて認可コード（code）を持ってリダイレクトされてきたら、バックエンド側（あるいはフロントエンド側）でアクセストークンを要求する。ここではPython（requestsライブラリ）の例を示す。
import requests
from fastapi import FastAPI, HTTPException, Request
app = FastAPI()
# 認可サーバー（IdP）のエンドポイント設定
TOKEN_ENDPOINT = "https://auth.ztna.enterprise.internal/oauth/token"
CLIENT_ID = "ztna-portal-client"
REDIRECT_URI = "https://portal.ztna.enterprise.internal/callback"
@app.get("/callback")
async def oauth_callback(code: str, request: Request):
# 注: 実際の実装では、フロントエンドから送られてきた code_verifier をセッション等から取得する
# ここでは便宜上、クライアントから受け取ったものとする
code_verifier = request.cookies.get("pkce_verifier")
if not code_verifier:
raise HTTPException(status_code=400, detail="PKCE Verifierが欠落しています")
# 認可サーバーへトークンリクエストを送信
payload = {
"grant_type": "authorization_code",
"client_id": CLIENT_ID,
"code": code,
"redirect_uri": REDIRECT_URI,
"code_verifier": code_verifier, # ここで生のVerifierを送信して検証させる
}
headers = {"Content-Type": "application/x-www-form-urlencoded"}
response = requests.post(TOKEN_ENDPOINT, data=payload, headers=headers)
if response.status_code != 200:
# 失敗時はログに詳細を吐かせてデバッグ
raise HTTPException(status_code=401, detail=f"トークン取得失敗: {response.text}")
token_data = response.json()
access_token = token_data.get("access_token")
# このアクセストークンをCookie（HttpOnly）等に格納し、ZTNAリソースへのアクセスに利用する
return {"status": "認証成功", "access_token_masked": access_token[:10] + "..."}—
5. 現場のトラブルシューティング：よくある「ハマりどころ」と対策
最後に、私がインフラの現場やコードレビューで何度も遭遇した、PKCEおよびZTNA連携時の「あるあるトラブル」と、その処方箋を共有しておこう。
トラブル1：invalid_grant が返されてアクセストークンが取れない
- 原因の多く：
code_verifierの文字エンコードミス、あるいは認可コード（code）の二重使用（Authorization Codeは一度使ったら即座に無効化される）。また、認可リクエスト時とトークンリクエスト時でredirect_uriの末尾のスラッシュの有無などが微妙に異なっているケースも非常に多い。 - デバッグのコツ： IdP（Keycloak, Auth0, Entra IDなど）の監査ログやアクセストラフィックをデバッグモードで有効にし、送信された
code_challengeと算出したハッシュ値が一致しているかをIdP側で追跡する。
トラブル2：CORS（Cross-Origin Resource Sharing）エラーでトークンエンドポイントに弾かれる
- 原因： パブリッククライアント（ブラウザ上のSPAなど）から直接IdPの
/tokenエンドポイントを叩いた際、IdP側で適切なCORSヘッダー（Access-Control-Allow-Originなど）が設定されていない。 - 処方箋： パブリッククライアントからの直接通信を許可するようにIdPの設定を見直すか、自社のBFF（Backend for Frontend）パターンを採用して、ブラウザからは自社ドメインのバックエンドへリクエストし、バックエンド経由でIdPと通信するアーキテクチャに設計変更する。セキュリティの観点からも、BFFパターンでアクセストークンをHttpOnly Cookieに閉じ込める手法を強く推奨する。
—
まとめ：境界なき時代の「確かな信頼」を築くために
「ネットワークの境界線」というかつての防壁が消え去った今、私たちが信頼できるのは、暗号学的な数学の証明と、エンドポイントの厳格な検証だけだ。
OAuth 2.0 認可コードフローとPKCEの組み合わせは、パブリッククライアントという「信用しきれない端末」からでも、安全かつ確実なユーザー認証とアクセスの認可を実現するための最強の武器となる。仕様書をただ眺めるだけでなく、パラメーターの裏側でどのようなハッシュ計算が行われ、どのようにトラフィックが流れているのかを理解していれば、どんな複雑なゼロトラスト要件であっても、自信を持ってセキュアなアーキテクチャを構築できるはずだ。
さあ、レガシーなVPNの呪縛から解放され、真のゼロトラストの扉を叩こう。
コメント