MCP の OAuth 2.1 PKCE 対応ガイド

Uncategorized

OpenAI の Model Context Protocol (MCP) に対応するアプリケーションでは、認可フローに OAuth 2.1 の Authorization Code + PKCE を実装することが求められます。PKCE は公開クライアントでも安全に認可コードフローを利用するための仕組みで、MCP の「Deep Research」コネクタなどを動作させる上で必須となります。本記事では PKCE の基本的な流れと OAuth 2.0 との違い、/authorize・/token の各エンドポイントでの変更点を解説します。

従来の認可コードフローではクライアントは固定の client_secret を使って自身を認証します。しかしブラウザやモバイルアプリのような公開クライアントでは client_secret を安全に保持できません。PKCE（Proof Key for Code Exchange）では以下の手順によってこの問題を解決します。

  1. code_verifier の生成
    クライアントは 43 文字以上のランダム文字列を生成し code_verifier として保持します。
  2. code_challenge の生成
    code_verifier を SHA-256 でハッシュし Base64URL エンコードしたものを code_challenge とします。ハッシュ方式は常に S256 を使用します。
  3. 認可リクエストに code_challenge を送信
    /authorize に code_challenge と code_challenge_method=S256 を含めてユーザー認証を行います。
  4. トークンリクエストで code_verifier を送信
    認可コードを受け取った後、/token リクエストのボディに code_verifier を code と一緒に送ります。サーバーは code_verifier から計算した code_challenge が初回リクエストの値と一致するか検証します。
  5. 一致すればトークンを発行
    code_challenge が一致すれば正規のクライアントとしてアクセストークン（必要ならリフレッシュトークン）を返します。

この仕組みにより攻撃者が認可コードを盗んでも code_verifier を知らなければ /token でトークンを取得できません。

OAuth 2.1 では /authorize リクエストで code_challenge と code_challenge_method=S256 の送信が必須になります。例:

GET /authorize?client_id=CLIENT_ID&
    response_type=code&
    redirect_uri=CALLBACK_URL&
    scope=read%20write&
    state=STATE_VALUE&
    code_challenge=BASE64URL(SHA256(code_verifier))&
    code_challenge_method=S256

state は CSRF 対策のためのランダム値で、リダイレクト時にそのまま返却する必要があります。OAuth 2.0 では code_challenge と code_challenge_method の送信は不要でした。

PKCE フローでは /token へのリクエストに client_secret を含めず、代わりに code_verifier を送信します。

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
client_id=CLIENT_ID&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL&
code_verifier=ORIGINAL_CODE_VERIFIER

認可サーバーは code_verifier から code_challenge を再計算して検証します。リクエストヘッダに Basic 認証を付ける必要もありません。

変更点 OAuth 2.0 OAuth 2.1
PKCE 公開クライアント向けに推奨で必須ではない すべてのクライアントで必須。code_verifier と code_challenge を必ず利用
Implicit フロー SPAs 向けに存在しアクセストークンを直接返す 廃止。SPAs も認可コード+PKCEを利用する
Resource Owner Password Grant ユーザーの ID・パスワードを直接送信してトークン取得が可能 廃止。代わりに認可コード+PKCEを使用
リダイレクトURIの一致 ワイルドカードなど柔軟な一致が可能 完全一致が必須。登録済みURIと完全一致しない場合は拒否
トークンの送信方法 クエリ文字列に含めることも許可 クエリ文字列での送信は禁止。Authorization: Bearer ヘッダ等で送る
  • MCP 対応アプリケーションでは /.well-known/oauth-authorization-server と /.well-known/oauth-protected-resource にメタデータを公開し、grant_types_supported に authorization_code（必要なら client_credentials）を含める。
  • tools_offered には MCP の規定に沿って必要なツールのみ（search や fetch など）を列挙する。
  • 認証されていないアクセスには 401 と WWW-Authenticate ヘッダを返し、resource_metadata に /.well-known/oauth-protected-resource の URL を示す。
  • /token エンドポイントでは client_secret の代わりに code_verifier を検証し、アクセストークンを発行する。

OAuth 2.1 ではすべてのクライアントで PKCE が必須となり、OpenAI MCP のような公開クライアントでも安全に認可コードフローを利用できるようになっています。/authorize で code_challenge を送信し、/token で code_verifier を検証するフローを正しく実装することで、MCP コネクタの安全な動作を実現できます。


Source link

AIが“思った通りに動かない”理由とコンテキストエンジニアリング 前の記事 ｢LM Studio｣ではじめるローカルLLM。“ガチ無料AI”を徹底解説 | ギズモード・ジャパン 次の記事

関連記事

コメント

この記事へのコメントはありません。