An enterprise MCP OAuth redirect URI must use HTTP or HTTPS.

Error message

An enterprise MCP OAuth redirect URI must use HTTP or HTTPS.

What it means

validateRedirectUri in packages/enterprise-mcp-client/src/enterprise-mcp-client.ts throws when the OAuth redirect URI uses a scheme other than http: or https:. Redirect URIs are registered with the authorization server and resolved by the browser, so the library enforces HTTP(S) (native apps typically use a loopback http://127.0.0.1 URI).

Source

Thrown at packages/enterprise-mcp-client/src/enterprise-mcp-client.ts:118

  if (connection.authorization.type === "api-key" && !connection.authorization.token.trim()) {
    throw new Error("An API key connection requires a non-empty token.")
  }
  const url = new URL(parsed.serverUrl)
  if (url.protocol !== "https:" && url.protocol !== "http:") {
    throw new Error("An enterprise MCP server URL must use HTTP or HTTPS.")
  }
  if (url.username || url.password) {
    throw new Error("An enterprise MCP server URL cannot contain embedded credentials.")
  }
  if (url.hash) throw new Error("An enterprise MCP server URL cannot contain a fragment.")
  return url
}

function validateRedirectUri(redirectUri: string): string {
  const parsed = redirectUriSchema.parse(redirectUri)
  const url = new URL(parsed)
  if (url.protocol !== "https:" && url.protocol !== "http:") {
    throw new Error("An enterprise MCP OAuth redirect URI must use HTTP or HTTPS.")
  }
  if (url.username || url.password || url.hash) {
    throw new Error("An enterprise MCP OAuth redirect URI cannot contain credentials or a fragment.")
  }
  return parsed
}

function configurationValue<T>(parse: () => T): T {
  try {
    return parse()
  } catch (error) {
    throw new EnterpriseMcpClientError({
      operationPhase: "configuration",
      requestPhase: null,
      cause: error,
    })
  }
}

View on GitHub (pinned to 2b7df46e8a)

Solutions

Use an http(s) redirect URI, e.g. http://127.0.0.1:<port>/callback for native apps or an https:// URL for web apps.
Register the HTTP(S) loopback redirect with the authorization server and use it in the client configuration.
If a custom scheme is required by your platform, handle the OAuth flow outside this client or front it with a local loopback listener.

Example fix

// before
redirectUri: "com.myapp://oauth/callback"

// after
redirectUri: "http://127.0.0.1:8765/callback"

Defensive patterns

Strategy: validation

Validate before calling

function assertHttpRedirectUri(redirectUri: string) {
  const u = new URL(redirectUri)
  if (u.protocol !== "https:" && u.protocol !== "http:") {
    throw new Error(`redirectUri must be http(s), got ${u.protocol}`)
  }
}

Prevention

For native apps, standardize on http://127.0.0.1:<port>/callback loopback redirects
Register exactly the same redirect string with the authorization server
Do not reuse custom-scheme configs from mobile OAuth libraries

When it happens

Trigger: Passing a redirect URI like "myapp://oauth/callback", "com.example.app:/oauth", or any custom-scheme URI to the client's OAuth/authorization setup.

Common situations: Porting a mobile/native OAuth config that used custom URL schemes into this client; copying a redirect URI from another OAuth library that accepted arbitrary schemes.

Related errors

AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01). Data as JSON: /api/errors/eea9b92e8d87210b. Report an issue: GitHub.