GoogleのOAuthは「動的クライアント登録」に対応していない──GooseのMCP拡張がv1.47.0で回避策を持った

MCP（Model Context Protocol）でリモートの拡張機能を使う際、認証サーバーがOAuthクライアントIDをどう発行するかは、実装によって差がある。Block社のオープンソースエージェント「Goose」は、v1.47.0（2026年8月21日公開）で、この差を吸収するための設定オプションを追加した。

「動的登録に対応していない認証サーバー」という壁

PR #11182（2026年8月14日マージ）の本文は、問題の所在をこう説明している。

"Remote MCP extensions currently obtain an OAuth client ID via Client ID Metadata Documents or Dynamic Client Registration. Authorization servers that support neither — they require a client registered out of band — hard-fail with Dynamic registration failed: Dynamic client registration not supported, with no way to supply the client ID goose was issued. Google's OAuth endpoints (used by the hosted Google Workspace MCP servers) are one example; several enterprise IdP setups ship the same posture (e.g. the Okta configuration in geelen/mcp-remote#270)."

（現状、リモートMCP拡張は、Client ID Metadata Documents（CIMD）またはDynamic Client Registration（DCR）のどちらかを通じてOAuthクライアントIDを取得する。そのどちらにも対応していない——つまりクライアントを帯域外（out of band）で登録することを求める——認証サーバーは、Dynamic registration failed: Dynamic client registration not supportedというエラーで完全に失敗し、Gooseに発行されたクライアントIDを渡す方法がなかった。Google Workspace MCPサーバー（ホスト型）が使うGoogleのOAuthエンドポイントはその一例であり、複数のエンタープライズIdP環境も同じ姿勢を取っている（例：geelen/mcp-remoteリポジトリのIssue #270にあるOktaの設定）)

つまり、MCPの仕様上は「クライアントが自動的に自分自身を登録できる」ことが前提になっている場面があるが、Googleのような大手プロバイダのOAuthエンドポイントや、一部の企業向けID基盤（Oktaなど）は、そもそもこの自動登録の仕組みに対応していない。この場合、Gooseは打つ手がなくエラーで止まっていた。

過去に一度close済みだった機能要望

このギャップ自体は以前から認識されていたようだ。PR本文にはこう書かれている。

"This is the gap described in #8918, and follows the config shape suggested there (a previous attempt was #10279, closed stale)."

（このギャップはIssue #8918で説明されており、今回の実装はそこで提案された設定形式に沿っている。以前にも1度実装が試みられたが（PR #10279）、それはstale（放置）としてクローズされていた）

過去の試みが一度立ち消えになった後、今回のPRで実際にマージされた、という経緯がうかがえる。

設定は3つのオプションフィールドを追加するだけ

実装が加えたのは、streamable_http拡張の設定に対する3つのオプションフィールドだ。PR本文が示す設定例はこうなっている。

extensions:
  example:
    type: streamable_http
    uri: https://example.com/mcp
    client_id: <registered client id>        # takes priority over CIMD/DCR
    client_secret_key: EXAMPLE_OAUTH_SECRET  # env/secret KEY NAME - value never inline
    scopes: [example.readonly]               # otherwise server metadata scopes are used

client_idを指定すると、CIMDやDCRより優先してこちらが使われる。client_secret_keyは、シークレットの値そのものではなく、環境変数または秘密情報ストアの「キー名」を指定する仕組みになっており、設定ファイルにシークレットの実値が直書きされることはない。scopesは省略時、サーバー側のメタデータが示すスコープにフォールバックする。

内部実装のポイント

PR本文には、実装の詳細もいくつか記載されている。

"oauth_flow builds the AuthorizationRequest with rmcp's with_preregistered_client / with_client_secret / with_scopes (the SDK already implements the MCP-spec priority: pre-registered → CIMD → DCR); without client_id, behavior is unchanged."

（oauth_flowは、rmcp（RustのMCP SDK）が持つwith_preregistered_client／with_client_secret／with_scopesを使ってAuthorizationRequestを組み立てる。SDK側はすでにMCP仕様が定める優先順位——事前登録済み→CIMD→DCR——を実装済みであり、client_idを指定しない場合の挙動は変わらない）

また、認証情報の永続化と再認証の扱いについても言及がある。

"Goose persists configured and granted scopes separately: changing the configured scope set re-authorizes once, while an unchanged narrowed grant is refreshed without a re-auth loop."

（Gooseは設定されたスコープと、実際に許可されたスコープを別々に永続化する。設定側のスコープ集合を変更すると1回だけ再認証が走るが、許可スコープが変わらず単に絞られているだけの場合は、再認証ループを起こさずにリフレッシュされる）

「設定を変えていないのに毎回再認証を求められる」といった、OAuth絡みでありがちな不具合を避けるための細かい配慮が入っていることが分かる。

同じリリースにOAuth関連の他の変更も：平文HTTPへのダウングレードを防ぐ修正

v1.47.0のリリースノートを見ると、このPRと同じ「OAuth」領域で他にも変更が入っている。該当する2件のPR本文を個別に確認した。

**PR #11183「Enforce secure token transport in OAuth」**は、DatabricksのOAuthコード交換・リフレッシュ処理が、発見したトークンエンドポイントをリモートの平文HTTP経由で受け入れてしまっていた、という問題を修正したものだ。

"The Databricks OAuth code-exchange and refresh paths accepted a discovered token endpoint over remote plaintext HTTP. That could expose short-lived authorization codes and long-lived refresh tokens in transit."

（DatabricksのOAuthコード交換・リフレッシュ処理は、発見されたトークンエンドポイントをリモートの平文HTTP経由で受け入れていた。これにより、短命な認可コードや長命なリフレッシュトークンが通信経路上で露出する可能性があった）

修正内容は、OAuthのdiscoveryとトークンエンドポイントにHTTPSを必須化しつつ、平文HTTPはループバックホスト（localhostなど）に限定して許可、リモートエンドポイント向けにはHTTPS専用クライアントを使い、307/308リダイレクトによる平文HTTPへのダウングレードも拒否する、というもの。この脆弱性は「Project Loupe」という社内トラッキング（PR本文に記載）で発見されたとされている。

**PR #11223「deprecated gemini oauth provider」**は、理由がシンプルだった。

"The gemini oauth provider is no longer working. More info in #11206. So we should deprecate it for now."

（gemini oauthプロバイダーはもう動作していない。詳細はIssue #11206を参照。そのため、いったん非推奨にすることにした）

「動かなくなったので非推奨にした」という、対処療法的な変更であることが分かる。Issue #11206自体の本文（動作しなくなった原因の詳細）までは、今回は追加で確認していない。

Google WorkspaceのMCP検証環境は持っていない

筆者自身はGoogle Workspace MCPサーバーやOktaを使った検証環境を持っていないため、この設定を実際に動かして確認することはできなかった。ただ、MCP拡張を使う際に「認証サーバー側がDynamic Client Registrationに対応しているか」という前提を意識したことはなく、Gooseのこの変更を読んで初めて、MCPのOAuth連携が「対応必須の標準」ではなく「対応しているサーバーとしていないサーバーが混在する」領域だと認識した。

Oktaの設定内容そのものは今回も確認できなかった

Issue #8918を追加で確認したところ、この機能要望は2026年4月29日にangiejones氏が起票したもので、当初の提案とPR #11182で実際にマージされた実装のあいだには、設定形式に次のような違いがあった。

当初案と実装のあいだで設定形式が変わっている点は、Issue本文とPR本文を突き合わせて初めて分かった。Issueにはまた、DCR非対応サーバーへの既存の回避策として「ローカルのstdioプロキシでOAuthを外部処理させる」方法があるが、プロセスやキャッシュ場所が増えて壊れやすいと書かれていた。

一方、geelen/mcp-remoteリポジトリのIssue #270（PR本文が言及していたOktaの設定例）は、今回アクセスすると404で開けず、内容を確認できなかった。同リポジトリまたは該当Issueが削除・非公開化されている可能性がある。開けなかったURLは出典に追加していない。

関連記事

• MCP（Model Context Protocol）とは──AIとツールをつなぐ共通規格
• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• AIエージェントとは──指示に答えるAIと、仕事を進めるAIの違いをわかりやすく整理する