Skip to content

Google Workspace MCP OAuth fails on accounts.google.com trailing-slash issuer mismatch #4606

Open

Description

@kimyu-ng

Describe the bug

Native HTTP MCP authentication fails for Google's official Workspace MCP
endpoints before the browser authorization flow begins.

The protected-resource metadata advertises this authorization server:

https://accounts.google.com/

Google's authorization-server/OpenID metadata advertises this issuer:

https://accounts.google.com

These URLs differ only by the trailing slash on the origin root, but Copilot CLI
compares them literally and rejects the server:

OAuth authentication failed for google-calendar: MCPOAuthError:
Incompatible authorization server: authorization server advertised an issuer
that does not match the URL its metadata was discovered from (RFC 8414 §3.3);
refusing to connect

This affects all seven currently documented Google Workspace MCP endpoints:

  • Calendar: https://calendarmcp.googleapis.com/mcp/v1
  • Gmail: https://gmailmcp.googleapis.com/mcp/v1
  • Drive: https://drivemcp.googleapis.com/mcp/v1
  • People: https://people.googleapis.com/mcp/v1
  • Docs: https://docsmcp.googleapis.com/mcp/v1
  • Slides: https://slidesmcp.googleapis.com/mcp/v1
  • Sheets: https://sheetsmcp.googleapis.com/mcp/v1

Each endpoint's protected-resource metadata currently returns:

{
  "resource": "<the MCP endpoint>",
  "authorization_servers": ["https://accounts.google.com/"]
}

Google's public metadata returns:

GET https://accounts.google.com/.well-known/openid-configuration
{
  "issuer": "https://accounts.google.com"
}

Affected version

GitHub Copilot CLI 1.0.81-10

Steps to reproduce the behavior

  1. Register the localhost OAuth redirect URI required by Google and configure
    Calendar as a native HTTP MCP server (credentials redacted):

    {
      "mcpServers": {
        "google-calendar": {
          "type": "http",
          "url": "https://calendarmcp.googleapis.com/mcp/v1",
          "oauthClientId": "<redacted>",
          "auth": {
            "clientSecret": "<redacted>",
            "redirectPort": 8080
          }
        }
      }
    }
  2. Start Copilot CLI.

  3. Run /mcp auth google-calendar.

  4. Authentication fails with the RFC 8414 issuer-mismatch error above. The
    browser consent flow never starts.

The same behavior occurs with the other Google Workspace MCP endpoints.

Expected behavior

Copilot CLI should be able to authenticate with Google's official Workspace MCP
endpoints.

Ideally, the implementation would preserve strict issuer validation while
canonicalizing only semantically equivalent origin-root URLs before selecting
the discovery issuer (or otherwise handling the empty-path/trailing-slash
equivalence safely). If that is not acceptable under the CLI's RFC 8414
validation policy, the error should identify the two compared values and
provide an actionable, narrowly scoped compatibility option.

Additional context

  • OS: macOS 26.6
  • Architecture: Apple Silicon (arm64)
  • Terminal: iTerm2
  • Shell: zsh

A pinned mcp-remote@0.2.4 stdio proxy using the same endpoint, OAuth client,
redirect URI, and Google account completes the OAuth flow successfully and can
call the Google tools. This confirms the client registration, consent, token
exchange, scopes, and MCP endpoints are functional; the failure is specific to
Copilot CLI's native HTTP MCP OAuth discovery/issuer validation.

Related reports:

This Google case is distinct: the protected-resource metadata uses the
RFC 9728 resource string and authorization_servers array correctly, and the
issuer differs only by a trailing slash at the authorization server's root.

Activity

  1. added
    area:authenticationLogin, OAuth, device auth, token management, and keychain integration
    area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry
    and removed on Aug 26, 2026
  2. dggsax commented on Sep 17, 2026

    @dggsax

    Thanks for the detailed report. We checked this against the latest MCP authorization specification (2026-07-28). Its Authorization Server Metadata Discovery section explicitly requires clients to validate metadata per RFC 8414 §3.3 (or OpenID Connect Discovery §4.3):

    the issuer value in the document MUST be identical to the issuer identifier used to construct the well-known URL. If they differ, the client MUST NOT use the metadata.

    RFC 8414 §3.3 uses the same requirement: the returned issuer "MUST be identical" to the identifier used to construct the discovery URL. Consequently, https://accounts.google.com/ and https://accounts.google.com do not match for this validation; a client-side trailing-slash normalization would violate the current MCP discovery requirements.

    The relevant specification text is here:

    Google's protected-resource metadata and authorization-server metadata therefore need to advertise the same issuer identifier. Copilot CLI should retain strict validation rather than add a provider-specific normalization for this case.

  3. travisbader commented on Sep 17, 2026

    @travisbader

    Copilot CLI should retain strict validation

    Spec aside, this MCP can be configured in Claude Code, Cursor, Codex, but broken in Copilot which makes it hard to sell as a viable solution. over a trailing slash? Normalizing trailing slashes seems trivial and not a complete violation of the RFC? Also FWIW— it appears to have worked previously in CLI 1.0.64.

  4. ViliusS commented on Sep 20, 2026

    @ViliusS

    @dggsax I'm afraid you are reading the specs wrong. RFC 8414 3.3 says:

    the returned issuer MUST be identical to the identifier used to construct the discovery URL.

    Also section 2 about issuer says:

    Authorization server metadata is published at a location that is ".well-known" according to RFC 5785 derived from this issuer identifier, as described in Section 3.

    This doesn't mean issuer and authorization_servers need to match completely. This means that only scheme and domain part needs to match. Everything else can be safely ignored if well-known URL can be discovered.

    By the way, error message itself is also wrong:
    OAuth authentication failed for google-calendar: MCPOAuthError:
    Incompatible authorization server: authorization server advertised an issuer
    that does not match the URL its metadata was discovered from
    (RFC 8414 §3.3);

    https://accounts.google.com/.well-known/openid-configuration does return issuer https://accounts.google.com which matches discovery URL identifier perfectly, and has nothing do to with authorization_servers in the resource document directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:authenticationLogin, OAuth, device auth, token management, and keychain integrationarea:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registry

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions