これまでのおさらい
はじめに
第1回ではMCPの全体像（Host／Client／Serverといった役割や、なぜMCPが必要なのか）を押さえました。第2回ではMCP Python SDKを使って天気予報MCPサーバーを実装し、MCP InspectorやVS CodeのGitHub Copilotからツールを呼び出すところまで動作確認しました。
今回は、いよいよ「インターネット上で動くMCPサーバー」を作り、さらに認証（authentication）と認可（authorization）を導入します。
本記事では、ホスティング先としてAzureを使い、認証基盤としてMicrosoft Entra IDを利用します。ただし本記事は「Azure特有のやり方を“正解”として押し付ける」ことが目的ではありません。
- Anthropicが公開しているMCPのAuthorization仕様（OAuth2.1をベース）を "軸" として理解する
- その具体的な実装例として、多くの企業で使われているMicrosoft Entra IDを使う
- ホスティング先として、Entra IDと親和性が高いAzure App Serviceを使う
上記の立て付けで進めます。
対象読者
- MCPの基本概念（第1回の内容）と、MCPサーバー開発（第2回の内容）を一通り触った方
- 「社内向け／個人検証向けにMCPサーバーを公開したい」方
- OAuth／OpenID Connectを名前だけでも聞いたことがある方（詳細は本記事内で必要最小限を説明します）
前提条件
Azureアカウント／権限
- Azureサブスクリプションを1つ持っていること
- Microsoft Entra IDテナント（通常はAzureとセット）を持っていること
-
少なくとも以下が可能な権限があること
- Azureリソースを作成できる
- アプリケーション登録を作成できる（組織ポリシーで制限されている場合は管理者に依頼）
注意：組織テナントでは「管理者の同意（admin consent）」が必要な設定になっている場合があります。その場合、後述の "同意の作成" で詰まるので、テナント管理者に協力を依頼してください。
ローカル環境
- Git
-
Azure Developer CLI（
azd） - Node.js（MCP Inspectorを使う場合）
- VS Code
- GitHub Copilot（VS CodeでMCPクライアントとして使います）
コストについて
本記事ではAzureにリソースを作成します。検証が終わったら削除（後片付け）まで行うことを推奨します（手順は最後に記載します）。
まず押さえる：MCPにおける「認証」と「認可」
後半はAzureの手順が中心ですが、ここで一度“概念”を揃えておくと混乱しにくくなります。
認証（authentication）と認可（authorization）の違い
- 認証（authn）：「あなたは誰ですか？」を確認すること（サインイン）
- 認可（authz）：「あなたは何をして良いですか？」を制御すること（どのクライアント／どの権限でMCPサーバーにアクセスできるか）
用語ミニ辞書（最小限）
AS／Resource Serverなどの「役割」は次の節で整理します。ここでは後段で頻出する用語だけ押さえます。
-
scope（スコープ）：何を許可するかの粒度（例：
user_impersonation） - resourceパラメータ：トークンを「どのリソース向けか」に束縛するための指定（RFC 8707）
- client_id：OAuthクライアント（例：VS Code）の識別子。許可リスト（許可されたクライアント）に使える
- consent（同意）：クライアントが特定のスコープでアクセスすることを、ユーザー（または管理者）が許可すること
- pre-registration（事前登録）：あらかじめ“許可するクライアント”を登録しておく運用（許可リスト方式）
- DCR（Dynamic Client Registration）：OAuthのクライアント登録を動的に行う仕組み（必須ではない）
- PRM（Protected Resource Metadata）：MCPサーバーの認証要件やAS などを、クライアントが発見するためのメタデータ
- PKCE：認可コードフローでの盗聴／すり替え対策（クライアントが必ず使う）
MCP Authorization仕様が前提にする役割
Anthropicの仕様では、HTTP transportのMCPをOAuth2.1に当てはめて整理します。
- MCP server（保護されたMCPサーバー）：OAuth2.1のResource Serverとして振る舞う
- MCP client（例: VS Code／GitHub Copilot）：OAuth2.1のClientとして振る舞う
- Authorization Server（AS）：ユーザーと対話してトークンを発行する（例：Entra ID）
仕様上の重要ポイント（今回のハンズオンに直結するもの）
仕様の全てを追う必要はありませんが、次の点は“この記事の手順がなぜ必要か”に直結します。
-
Protected Resource Metadata（PRM）は必須（MUST）
- MCPクライアントは、MCPサーバーが「どのAuthorization Serverを使うのか」をPRMから発見することが必須です。
-
PRMのwell-knownは
/.well-known/oauth-protected-resourceです。
-
PKCEは必須（MUST）
- 認可コードフローでの盗聴／すり替え対策として、クライアントはPKCEを必ず使う必要があります。
-
resourceパラメータ（RFC 8707）は必須（MUST）
-
トークンを「このMCPサーバー専用」に束縛するために、クライアントは
resourceを認可リクエストとトークンリクエストの両方に含める必要があります。
-
トークンを「このMCPサーバー専用」に束縛するために、クライアントは
-
Dynamic Client Registration（DCR）は任意（MAY）
- DCRは必須ではありません。代わりにpre-registration（事前登録）や、Client ID Metadata Documents（CIMD）が想定されます。
