Skip to content

feat(http): add --authorization-server flag to override OAuth AS URL#2900

Open
Anika-Sol wants to merge 1 commit into
github:mainfrom
Anika-Sol:feat/authorization-server-override
Open

feat(http): add --authorization-server flag to override OAuth AS URL#2900
Anika-Sol wants to merge 1 commit into
github:mainfrom
Anika-Sol:feat/authorization-server-override

Conversation

@Anika-Sol

Copy link
Copy Markdown
Contributor

Summary

Adds a --authorization-server CLI flag (and GITHUB_AUTHORIZATION_SERVER env var) to the http subcommand, allowing operators to override the authorization server URL advertised in the OAuth Protected Resource Metadata (/.well-known/oauth-protected-resource).

Why

When deploying the MCP server against GitHub Enterprise Server, GHES does not natively support RFC 8414, RFC 7591, or PKCE — making direct MCP OAuth impossible. A common solution is to deploy a thin OAuth proxy in front of GHES that implements the MCP OAuth spec. However, the MCP server always derives authorization_servers from GITHUB_HOST, so clients are pointed at GHES directly instead of the proxy. Without this flag, operators must intercept /.well-known/oauth-protected-resource at the ingress layer as a workaround.

The AuthorizationServer field already exists in pkg/http/oauth/oauth.Config with the conditional in place — it simply wasn't reachable from any configuration surface.

What changed

  • Added AuthorizationServer string field to pkg/http/server.go ServerConfig
  • Wired cfg.AuthorizationServer into the oauth.Config struct in RunHTTPServer
  • Added --authorization-server flag on httpCmd in cmd/github-mcp-server/main.go
  • Added viper binding so GITHUB_AUTHORIZATION_SERVER env var works automatically

MCP impact

  • No tool or API changes — only affects OAuth metadata discovery; no tools, schemas, or API behavior changed

Prompts tested (tool changes only)

  • N/A

Security / limits

  • Auth / permissions considered — when set, this flag redirects clients to a different authorization server. Operators are responsible for ensuring the configured URL points to a trusted proxy. No change to token validation or API access control.

Tool renaming

  • I am not renaming tools as part of this PR

Lint & tests

  • Linted locally with ./script/lint
  • Tested locally with ./script/test

Docs

  • Not needed
  • Updated (README / docs / examples)

When deploying the MCP server behind an OAuth proxy (e.g. for GHES,
which does not natively support RFC 8414, RFC 7591, or PKCE), the
/.well-known/oauth-protected-resource endpoint currently always derives
the authorization_servers URL from GITHUB_HOST. There is no way to
point clients at a different authorization server without intercepting
that endpoint at the ingress/proxy layer.

The oauth.Config struct already has an AuthorizationServer field with
the conditional logic in place (pkg/http/oauth/oauth.go), but it was
never wired to any configuration surface.

This commit exposes it as:
- --authorization-server CLI flag on the http subcommand
- GITHUB_AUTHORIZATION_SERVER environment variable (via viper's
  existing GITHUB_ prefix + automatic env mapping)

When set, the value is passed through ServerConfig into oauth.Config,
and the protected resource metadata advertises it directly instead of
calling apiHost.AuthorizationServerURL().
@Anika-Sol
Anika-Sol requested a review from a team as a code owner July 17, 2026 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant