Claude Media
Claude Code MCPでAADSTS9010010が出る原因 — Entra ID連携の詰まり
Claude CodeMCPClaude連携Tips

Claude Code MCPでAADSTS9010010が出る原因 — Entra ID連携の詰まり

Entra IDで保護したMCPサーバーにClaude Codeからつなぐと、接続時はAADSTS9010010、再接続時はAADSTS650053で失敗します。原因のresource衝突と切り分け方を示します。

読了目安 約9分

Microsoft Entra ID(旧Azure AD)で保護したMCPサーバーにClaude CodeのネイティブOAuthでつなぐと、ブラウザーでのサインイン直後に「AADSTS9010010」で失敗します。いったん繋がった後の再接続では、別のエラー「AADSTS650053」が出ます。どちらもサーバーの実装ミスではなく、Claude Code側が送るresourceパラメーターとEntra側の要求が食い違うことが原因として報告されています。

issue #89438はopenのままで、修正が入ったバージョンはまだありません。

AADSTS9010010は何を言っているか

エラーの全文は次のとおりです。

invalid_target: AADSTS9010010: The resource parameter provided in the request
doesn't match with the requested scopes.

読み解くと、認可リクエストのresourceと、要求したscopeが属するアプリのあいだに食い違いがある、という意味です。issue #73460の報告では、Entraはresourceを、スコープを持つアプリの識別子URI(api://<app-id>)と完全一致させるよう強制しています。強制が始まったのは2026年3月ごろと、報告者は書いています。

一方、Claude CodeはMCPの認可仕様に沿って、RFC 8707のresourceをサーバーのprotected resource metadata(/.well-known/oauth-protected-resource)の値から決めます。値は多くの場合、MCPサーバー自身のURLです。そのURLがapi://形式の識別子URIと一致することは、まずありません。

くらべる

resourceに何を載せると、どちらが落ちるか

Entra側で失敗

metadataのresourceがサーバーURL

Claude Codeの検証は通ります。しかしEntraの/authorizeがAADSTS9010010を返します。

Claude Code側で失敗

metadataのresourceが api://アプリID

Entraは受け付けます。しかしClaude Codeがサーバー自身のURLとの不一致を理由に、ブラウザーを開く前に止まります。

api://アプリIDに寄せた右側の案で出るメッセージは、issue #76096に次の形で載っています。

SDK auth failed: Protected resource api://<app-id-guid> does not match expected https://<server-host>/mcp (or origin)

つまりサーバー側のmetadataをどちらに寄せても、片方は必ず落ちます。#76096はこれを「相互排他」と呼んでいます。両方を満たせるのは、サーバーのURL自体がEntraに登録された識別子URIになる場合だけです。ただし報告によれば、Entraは検証済みドメインでないHTTPS識別子URIを受け付けません。Azure Functionsの*.azurewebsites.netのようなホスト名では、この道は使えません。

接続時と再接続時でエラーが変わる

#89438が新しく加えたのは、再接続の経路です。同じ症状に見えて、エラーコードも出るタイミングも違います。

場面エラー何が起きているか(報告者の見立て)
初回の接続(/mcpでサインイン)エラーAADSTS9010010何が起きているか(報告者の見立て)resourceにサーバーURLを送り、Entraの完全一致チェックで拒否される
再接続(/mcpの再接続、Claude DesktopのカスタムコネクタのReconnect)エラーAADSTS650053何が起きているか(報告者の見立て)resourceやスコープの修飾が落ち、Entraが既定でMicrosoft Graphを対象にする

再接続時のメッセージは次の形です。

AADSTS650053: The application '<app>' asked for scope 'mcp.read' that doesn't exist
on the resource '00000003-0000-0000-c000-000000000000'.

00000003-0000-0000-c000-000000000000は、Microsoft Graphのよく知られたアプリIDです。自分のAPIのスコープを要求したつもりが、Graphに対するスコープとして解釈されて「そんなスコープは存在しない」と返ります。報告者はこの流れを、リフレッシュ経路がresourceの指定を落としている可能性があると推測しています。確定した原因ではない点には注意が要ります。

Claude Code側の表示はどちらの場合も「Authorization failed」程度で、Entraのエラーページや詳細は出ません。AADSTS650053を別のバグと取り違えやすいのは、このためです。

Claude Code側に逃げ道はあるか

ドキュメントのoauth設定には、次のキーが載っています。

  • clientIdとcallbackPort: 事前登録したOAuthクライアントと、固定のコールバックポート
  • scopes: 要求するスコープを固定する(スペース区切りの1つの文字列)
  • authServerMetadataUrl: 認可サーバーのmetadataのURLを直接指定し、既定の探索を飛ばす

resourceの値を上書きするキーや、パラメーターを省略するスイッチは、MCPのドキュメントに記載がありません。#73460の報告者も、既存のどのoauth設定でもresourceの値は変えられないとしています。

その根拠として、Entraの/authorizeを直接叩いた結果が表で載っています。

scoperesource結果
api://<app>/my.scoperesourceMCPサーバーのURL結果AADSTS9010010
スコープ名のみ(my.scope)resourceMCPサーバーのURL結果AADSTS9010010
api://<app>/my.scoperesourceapi://<app>結果受理
api://<app>/my.scoperesource省略結果受理

スコープをどう書き換えても通らず、resourceの値か有無だけが結果を決めています。#73460はこの事実から、.mcp.jsonのoauthにresourceキーを足す提案をしました。Entraが受け付けるのは上書きか省略のどちらかだからです。ところがこのissueは2026年8月22日にnot plannedでクローズされ、#76096も重複として閉じられました。#89438の本文によれば、#73460は何の反応も得られないまま自動クローズされたため、改めて起票し直したものです。

oauth.scopesの固定やauthServerMetadataUrlの指定は、スコープや探索の問題を切り分けるときには役立ちます。ただし、この resource の衝突そのものは、これらでは解消しません。

いま取れる切り分けと回避の方向

Claude Codeのクライアントを直す手段がない以上、手元でできるのは「原因がこの衝突か」を見極めることと、衝突を避ける構成を選ぶことです。

手順

原因の切り分けの流れ

  1. 1

    エラーコードで経路を分ける

    サインイン直後のAADSTS9010010ならresourceの食い違い、再接続だけで出るAADSTS650053なら、リフレッシュ経路の問題を疑います。

  2. 2

    サーバー側が正しいことを先に確かめる

    #89438の報告者は、MSALのデバイスコードフローでEntraに直接つなぎ、得たトークンでサーバーを呼んで正常動作を確かめています。サーバーが正しいと分かれば、残る原因はクライアントのresourceの扱いに絞れます。

  3. 3

    トークンのaudを見る

    同じ報告者によると、クライアントとリソースが同じアプリ登録の構成(単一アプリの典型的なMCP構成)では、audがapi://付きではなく、素のGUIDになります。

  4. 4

    サーバーが受け入れるaudを揃える

    手動で取得したトークンを通すには、サーバーがこの素のGUIDも受け入れる必要がありました。報告者のAPIでは、許可するaudienceの3つ目の値として追加しています。

3つ目の手順は、Claude Codeを使わない検証の話です。Claude Codeが将来この衝突を解消したとき、サーバー側が素のGUIDのaudを受け入れていなければ、次はそこで詰まる可能性があります。

回避の選択肢としては、#76096の報告者が挙げた構成が参考になります。サーバーのURL自体を、テナントで検証済みのカスタムドメインにして、そのHTTPS URLをアプリの識別子URIとして登録するやり方です。*.azurewebsites.netや*.azure-api.netのような共有ドメインでは使えません。#73460が扱ったAWS Bedrock AgentCore Gatewayのようなマネージドホストでは、広告するresourceを変えられないため、この構成も取れません。

似た症状との見分け方

OAuthのサインインで止まるエラーは、原因が複数あります。AADSTS9010010とは別物のものを挙げます。

AADSTS番号が表示に出ていれば、先頭のAADSTSで始まる番号はEntraが返したものです。この番号が出ているなら、Claude Code自体の不具合ではなくEntraの応答が直接の理由と読めます。番号が出ない場合は、/mcpの詳細表示に含まれるサーバー報告のテキストを見ます。

Claude Codeの認証の仕組みとの関係

Claude Codeは、まずRFC 9728のProtected Resource Metadataを調べ、次にRFC 8414の認可サーバーmetadataへ戻る順で探索します。この探索の全体像と、リモートMCPのOAuthが版を重ねてどう変わってきたかは、リモートMCPのOAuth認証で扱っています。Entraの問題は、探索の結果得たresourceの値を、そのまま認可リクエストに載せる設計と、Entraの厳格な一致チェックがぶつかった例です。

まとめ

AADSTS9010010は、Entraがresourceをアプリの識別子URIに完全一致させる一方、Claude Codeがサーバー自身のURLをresourceに使うことで起きます。AADSTS650053は再接続の経路で別の形で現れ、Graphが対象になるという紛らわしいメッセージになります。いまのClaude Codeのoauth設定にはresourceを上書きするキーがないため、設定だけでは直せません。検証済みカスタムドメインの利用か、修正を待つかの判断になります。修正が入ったかどうかは、issue #89438の状態と、Claude Codeの更新履歴で確かめられます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →