今回作るもの（構成）
今回は「天気予報MCPサーバー」そのものを自作するのではなく、IaCとコードが揃った公式サンプルを使って"認証・認可の導入"に集中します。
- デプロイ対象：Azure App Service（Webアプリ）
- 認証基盤：Microsoft Entra ID
-
MCP endpoint：
https://<your-app-service-name>.azurewebsites.net/mcp/stream
参考：サンプル
手順1：Azure App ServiceにMCPサーバーをデプロイする
まずはホスティングです。azdを使うと、アプリと必要なAzureリソースをまとめて作成してデプロイできます。
azd（Azure Developer CLI）は、アプリ開発向けに「リソース作成（IaC）＋デプロイ」をプロジェクト単位でまとめて扱えるCLIです。
-
azd auth login：azdがAzureに操作できるようにサインインします（すでにサインイン済みなら省略できる場合があります） -
azd up：必要なAzureリソースを作成し、アプリをビルド・デプロイまで一括で実行します
git clone git@github.com:Azure-Samples/remote-mcp-webapp-python.git cd remote-mcp-webapp-python azd auth login azd up
実行中に「環境名（environment name）」と「リージョン」を聞かれるので、任意の値を入力してください。
デプロイが完了すると、出力にアプリのURLが表示されます。以降の手順で使うので記録しておきます。
手順2：MCP Inspectorから（認証なしで）動作確認する
認証・認可を入れる前に、まず「サーバーが動いている」ことを確認します。
npx @modelcontextprotocol/inspector
MCP Inspector側で、以下のように設定します。
-
Transport Type：
Streamable HTTP -
URL：
https://<your-app-service-name>.azurewebsites.net/mcp/stream
<your-app-service-name>は先ほど記録した値を使ってください。
注意：MCP InspectorはNode.js環境が必要です。Node.jsが無い場合は先にインストールしてください。
手順3：MCPサーバーに認証（Entra ID）を導入する
ここからが本題です。Azure App Serviceには組み込み認証（Easy Auth）という機能があり、アプリの前段でEntra ID認証を行えます。
この仕組みを使うと、アプリ（MCPサーバー）側でOAuth／OIDCの実装を一から書かなくても、まず「未認証アクセスをブロックする」状態を作れます。
ここでのポイントは「何をApp Service側（Easy Auth）に任せ、何がアプリ側に残るか」を誤解しないことです。
- Easy Auth が主にやってくれること：未認証リクエストのブロック／サインイン誘導／トークン発行元（Entra ID）とのやり取り
- アプリ側に残ること（例）：どのスコープを要求するかの設計、ログ・監査、MCPツール単位の権限分離（必要なら）など
IDプロバイダーから「Microsoft」を選択して「追加」を押下します。
これによって、MCPサーバーに対してMicrosoft Entra IDを使った認証が導入されます。
（結果として、あなたのテナント内のEntra IDユーザーだけがサインインできる状態になります）
参考：組み込み認証の概要
手順4：同意を作成する（詰まりポイント）
Entra IDを使う場合、MCPクライアントがトークンを取得するまでに「同意（consent）」が必要になるケースがあります。
特にVS Code+GitHub Copilotのようなクライアントでは、状況によって同意画面が出ず、結果としてサインインが進まないことがあります。
この問題への対策として、以下2つの考え方があります。
- 事前認証（pre-authorize）：既知のクライアントを許可リストに入れ、同意が必要な体験を最小化する（推奨）
- 同意を明示的に作る：開発／テストとして、ブラウザで直接サインインして同意を作っておく
開発／テスト目的で、ブラウザーで以下にアクセスしてサインインし、同意を作成できます。
URL：https://<your-app-service-name>.azurewebsites.net/.auth/login/aad
無事に同意が完了すると、以下のような画面が表示されます。
.auth/login/aadにアクセスし、Entra IDにサインインして同意を作成する参考：Overview
手順5：認可を設定し、アクセス元クライアントを制限する
次に認可（authorization）の設定です。
「認証」は“誰か”を識別する仕組みでしたが、「認可」はどのクライアントからのアクセスを許すかやどの権限（スコープ）を与えるかを制御します。
ここでは例として、VS Codeからのアクセスだけを許可します。
5-1．App Service側で「許可されたクライアント」を設定する
Azureポータルの「認証」ブレードから追加したMicrosoft IDプロバイダーの編集画面を開き、「クライアント アプリケーションの要件」を「特定のクライアントアプリケーションからの要求を許可する」に変更します。
その上で「許可されたクライアントアプリケーション」にVS CodeのクライアントIDを追加します。
-
VS Code client_id：
aebc6443-996d-45c2-90f0-388ff96faa56
注意：client_idは将来変更される可能性があります。値に不安がある場合は、公式ドキュメントで「VS Code（GitHub Copilot）が使うクライアントID」を確認してください。
-
VS Code client_id（執筆時点の例）：
aebc6443-996d-45c2-90f0-388ff96faa56
この構成は、MCP Authorization仕様でいう「pre-registration（事前登録）」の考え方に近いです。つまり、接続してよいクライアント（client_id）を“あらかじめ知っている”前提で許可します。
5-2．アプリ登録側（APIの公開）でもクライアントとスコープを許可する
続いて、同じ画面から「APIの公開」ブレードに移動し、「+クライアントアプリケーションの追加」を押下します。
VS CodeのクライアントID（aebc6443-996d-45c2-90f0-388ff96faa56）を追加し、「承認済みスコープ」内のapi://<アプリ ID>/user_impersonationをチェックして追加します。
Tip：user_impersonationは「ユーザーとしてアプリにアクセスしてよい」ことを表す代表的なスコープです。MCPの世界では、この“スコープ”が「どの操作まで許すか」を表す基本単位になります。
