MCP認証はどのように行われますか? OAuthチェーンを監査する

保護された遠隔MCPサーバでは, 認証は,単一のトークンチェックではありません. これは権限連鎖です. クライアントは課題を受け取り,正確な保護されたリソースのメタデータを発見し,権限サーバを発見し検証し,クライアントのアイデンティティを取得し,PKCEとリソース指数で権限コードフローを実行し,必要な範囲を受け取り,結果のトークンが意図されたMCPエンドポイントで動作することを証明します. その答えには重要な限界がある. 現在のMCP許可の仕様は,認証をオプションにするとともに,HTTPベースのトランスポートにOAuth経路を適用する. ローカル STDIO サーバは,ホスト環境または他のローカルメカニズムを通じて認証を取得すべきです. したがって,MCP接続ごとにブラウザフローを起動することは合理的なデフォルトではありません. 操作上の問題は, 私はトークンを持っているか? この特定の認証チェーン内のすべての結合が一致していることを示す領収書です. トークン状の文字列は,間違ったリソース,信頼されていない発行者,欠けている範囲,または 401 を返却する保護された要求と共存することができます. 輸送と最初の挑戦から始めましょう MCP認証教程の公式は,遠隔HTTPフローを段階的に説明します. 凝縮された形式: 1. クライアントは,トークンなしでMCP要求を送信します. 2. 保護された MCP サーバは, Bearer 401 Unauthorized / WWW Authenticate 課題で 401 Unauthorized を返します. 3. 課題は resource metadata を通じて保護された資源のメタデータを指します. 4. そのメタデータは,保護されたリソースと1つまたは複数の認証サーバーを識別する. 5. クライアントは許可サーバーのメタデータを取得し,発行者とエンドポイントを検証します. 6. クライアントは権限サーバがサポートするメカニズムを通じてクライアント IDを取得し,PKCEとMCPリソース識別子で権限コードフローを実行します. 7. クライアントは,MCPサーバーに生成されたアクセストークンを送信し,保護された要求を観察します. 最初の 401 は抑制に失敗していない. 発見の領収書です 有用な記録は HTTP ステータス,認証スキーム,メタデータ URL,観測時間,および選択された MCP リソースを保持します. Xnot は Authorization ヘッダー,クッキー,権限コード,検証,クライアント秘密,またはアクセストークンを保持します. RFC 9728は保護されたリソースのメタデータとよく知られている発見パターンを定義する. https://mcp.example/mcp のメタデータは,関連のないサービスによって提供された類似のホストまたはURLではなく,そのリソースを記述する必要があります. エラーボディからの任意の許可URLをフォローすることは等価ではありません. 権限サーバーは別々の役割です 保護された MCP サーバは OAuth リソース サーバとして機能する; MCP クライアントは OAuth クライアントとして機能する; 権限 サーバは必要に応じてユーザーと相互作用し,アクセストークンを発行する. これらの役割を混ぜることで,一般的なトラブルシューティングの間違いが妥当に見えます. クライアントが正しい発行者を発見したかどうかを確認する前に,リソースサーバートークンを回転します. 資源,発行者,クライアント,およびコードフローを結合する 2つのURLは正確な比較に値する. 保護された資源です RFC 8707 は resource リクエストパラメータを定義し,認証サーバーがトークンの意図された受信者を認識します. 現在のMCP草案には,許可およびトークン要求の両方でリソースパラメータが必要です. 別のAPIに発行されたアクセストークンは,選択されたMCPサーバに対してほぼ有効ではない. 2つ目は許可サーバー発行者です ブラウザを開く前に,クライアントは認証された認証サーバーのメタデータから発行者を記録します. 認証応答に iss が含まれている場合,現在のMCP草案は,クライアントがコードをトークンエンドポイントに送信する前に記録された値と比較することを記述します. 発行者の不一致は停止条件であり,両端点に対して同じコードを試す理由ではありません. クライアント登録も明示的な層です クライアントは,クライアント ID メタデータ ドキュメント,事前に登録されたクライアント ID,またはサポートされているダイナミック登録経路を使用することができます. 現在の草案では,ダイナミッククライアント登録は普遍的な仮定ではなく,互換性メカニズムとして扱われます. サポートされている登録メカニズムがない場合,正しい判決は registration blocked です. リダイレクト URIを発明したり,別の製品のクライアントIDを再利用すると,実際の相互運用性障害が隠されます. PKCEは,許可要求を後代コード交換に結びつける. 監査は,流れが拘束された検証者を保持していたかどうかを記録するのみであり,検証者は決して保持していない. ブラウザがコードを返したとしても,欠けている結合は unsafe flow になります. これは健康な固定装置に使用された内容のない形です スコープの名前とは,秘密の値ではなく,構成の証拠です. 敏感な部署では,まだ能力を明らかにできるので,健康決定に必要なものだけを保持し,他の運用メタデータと同じアクセス制御を行います. 最初の失敗層を診断する チェックリストは矛盾する行動を生み出します 保護された資源のメタデータは利用できない場合,発行者比較には信頼できる入力がない. 資源識別子は誤っている場合,より広い範囲を要求することは,それを修復することはできません. したがって,分類者は優先順位を使用し,最初の失敗層で停止します. 判決 鎖を止める証拠 次のアクションを制限する not applicable ローカル STDIO輸送 ランタイムのローカルクレジットメカニズムを使用する invalid challenge HTTPS resource metadata が欠けているか欠けているか 401 課題を修復する metadata unavailable 保護された資源のメタデータは 200 に返還されなかった メタデータを復元する.発行者を推測するな. resource mismatch メタデータまたはトークンは別のリソースをターゲットとする 資源の識別を正すか,資源に縛られたトークンを要求する issuer mismatch 発見されたまたはリコールバック発行者が同意しない 流れを拒絶し,メタデータ管理機関を調査する registration blocked サポートされたクライアントの身分がない サポートされている登録メカニズムを設定する unsafe flow 認証コードフローは PKCE 結合がない PKCEで再起動する step up required 現在の運用には許可されていない範囲が必要です 異議を唱える範囲のみを要求する token rejected 義務付けは同意するが,保護された要請は依然として失敗する 転機前に新しい課題を分類する authorized ready 許可の領収は全て一致し,申請は成功します MCPの初期化と結果チェックを継続する 供給された装置はネットワークアクセスなしに再生できます. 裁判は10件 裁判は10件 1件 authorized ready そして secretFieldsStored: 0 . この結果は意図的に9つのエラーと1つの成功よりも厳格である. 決定規則は,地元の輸送,発見失敗,矛盾するアイデンティティ,サポートされていない登録,不安全なコードフロー,欠けている範囲,拒否されたトークンとの間の有意義な違いを維持していることを証明します. 失敗した第一層のルールも 再試を制限します metadata unavailable は,制限されたメタデータの再試行を正当化することができる. issuer mismatch はそうすべきではない. step up required は,異議を唱える範囲のための新たな同意流を正当化することができる. token rejected は新しい挑戦を読み取らなければならない. 期限切れ,撤回,視聴者,および範囲は,一つの修理を共有していないからです. 範囲アップをトークン失敗から分離して 現在のMCP草案では,サーバーが WWW Authenticate 課題に必要な範囲を記載することを推奨する. 現行の操作について疑問視される範囲は,その操作に対して権威あるものであり,リソースメタデータの scopes supported セット全体に等しくする必要はありません. これにより,オペレーターの決定が変わります. files:read で読み取りが成功すると,書き込みは 403 と files:write に対する挑戦を返します. それは シンボルストアが腐敗している証拠ではない. これは step up required 状態です 顧客は,人間の視野で欠けている許可を求め,他の操作に必要な許可を保持しなければならない. 一方,資源,発行者,登録,PKCE,および範囲領収書が合意した後, 401 を返却する保護された要求は, token rejected です. 次のステップは 新しい挑戦を分類することです 同じトークンを繰り返し提示することは 進歩ではなく活動です 信用証明書の回転は 有用な証拠を破壊し 健康な顧客を 邪魔する可能性があります authorized ready の判決は狭いままです リモートMCPサーバーが この要求の許可チェーンを受け入れたと書かれています 書いてない: MCPの初期化と能力交渉が成功した. 選択したツールはまだ存在するか,そのスケーマが変更されていないか. 意図された外部効果を生んだツール呼び出し 副作用は,タイムアウト後に再試しても安全である. ユーザーの配達可能は存在します. 認証サーバー,クライアント,リソースはグローバルに信頼されています. これらの決定は健康と安全に関するものです 成功した保護要求は,実行をMCPライフサイクルチェックに移動し,次にツール効果および結果検証を直接 エージェント・サネーへ移動すべきです. 証明書収集せずに領収書を使用する 生産操作では,選択されたクライアントとリソースのためのハッシュまたは安定IDを,イベントを関連付けするために必要な場合にのみ保存します. メタデータとプロトコルルールが進化しているため,タイムスタンプと仕様バージョンを記録する. ソーストークン,コード,検証,秘密,クッキー,プロンプト,ツール・アルグメント,ツール結果を健康記録から削除する. 装置は分類器で ライブコンフォームスイートではありません 報告された観測を信頼している. リアル実装は TLS,メタデータ起源,リダイレクトURI,発行者行動,トークン署名または内視,視聴者,有効期限,展開ポリシーをさらに検証する必要があります. 2026年7月30日にMCPの草案が確認されました. 契約変更時に実行した仕様を書き込み,設定を再起動します. Sidewispの意図された製品領域には,ツールアクセシビリティ,期限切れの認証,許可喪失,有用な進歩,結果検証が含まれます. Sidewisp は現在プライベートプレビュー段階です。 Sidewispは既にMCP認証監査を実施していると主張するのではなく,この記事では独立した運用規則を提供している. MCP認証はどのように機能するかという実用的な答えは,持有符号のスクリーンショットではなく,承認領収書のチェーンです. 最初の矛盾を診断として扱って,制限された修復を1つ適用し,承認の成功をツール成功とユーザの最終的な結果から別にしておく.