forge mcp login OAuth flow requests hardcoded scopes instead of discovering scopes_supported

[nlenepveu]

Description

When using forge mcp login <server> with an MCP server that uses OAuth, the authorization request always uses a hardcoded scope set (profile email), ignoring the scopes_supported advertised by the server.

Expected Behavior

Per the MCP Authorization spec:

If scope is not available from the WWW-Authenticate header, clients SHOULD use all scopes defined in scopes_supported from the Protected Resource Metadata document.

Forge should discover the /.well-known/oauth-protected-resource/<endpoint> metadata and request all advertised scopes during the OAuth authorization flow.

Actual Behavior

Forge always requests scope=profile email in the OAuth authorization request, regardless of what scopes the MCP server advertises via its protected resource metadata.

This means servers that require scopes like:

• mcp:tools
• mcp:prompts
• mcp:resources
• offline_access

...receive tokens with insufficient scope, causing authorization failures downstream.

Steps to Reproduce

1. Set up an MCP server with OAuth that advertises scopes_supported beyond profile email in its /.well-known/oauth-protected-resource/<endpoint> metadata
2. Run forge mcp import --scope user with this server
3. Run forge mcp login <server-name>
4. Observe that the authorization request only includes profile email in the scope parameter

Environment

• Forge version: 2.12.14
• The server adheres to the MCP OAuth protected resource metadata spec

Suggested Fix

During the OAuth authorization flow, Forge should:

1. Fetch /.well-known/oauth-protected-resource/<endpoint> from the MCP server
2. Parse scopes_supported from the response
3. Request all supported scopes in the authorization request (falling back to openid profile email only if the endpoint is not reachable or has no scopes_supported)

[nlenepveu]

Code Evidence

I traced the OAuth flow through Forge and rmcp source code. Here are the findings:

1. forge mcp login passes empty scopes

File: crates/forge_infra/src/mcp_client.rs:650-651

oauth_state
    .start_authorization(&[], redirect_uri, Some("Forge"))

The scopes vector is &[] (empty). This is in the mcp_auth() function that backs the forge mcp login <server> CLI command.

2. What rmcp does with empty scopes

File: rmcp auth.rs -- start_authorization_with_metadata_url:

let selected_scopes: Vec<String> = if scopes.is_empty() {
    manager.select_scopes(None, &[])    // <-- called with empty default
} else {
    let mut s: Vec<String> = scopes.iter().map(|s| s.to_string()).collect();
    manager.add_offline_access_if_supported(&mut s);
    s
};

Since Forge passes empty scopes, rmcp calls select_scopes(None, &[]).

3. rmcp scope selection priority

File: rmcp auth.rs -- select_base_scopes:

fn select_base_scopes(
    &self,
    www_authenticate_scope: Option<&str>,
    default_scopes: &[&str],
) -> Vec<String> {
    // 1. scope from WWW-Authenticate header
    if let Some(scope) = www_authenticate_scope { ... }
    // 2. scopes from initial 401 WWW-Authenticate header probe
    if let Ok(guard) = self.www_auth_scopes.try_read() {
        if !guard.is_empty() { return ... }
    }
    // 3. scopes_supported from protected resource metadata (RFC 9728)
    if let Ok(guard) = self.resource_scopes.try_read() {
        if !guard.is_empty() { return ... }
    }
    // 4. scopes_supported from authorization server metadata
    if let Some(metadata) = &self.metadata {
        if let Some(scopes_supported) = &metadata.scopes_supported { ... }
    }
    // 5. default_scopes -- empty &[]
    default_scopes.iter().map(|s| s.to_string()).collect()
}

Steps 1-3 depend on successful server discovery. Step 4 depends on AS metadata containing scopes_supported. If none of these populate, step 5 returns empty, because default_scopes is &[].

4. Contrast with the interactive auth path

There is a second code path in mcp_client.rs:312-328 that does pass configured scopes:

let scopes: Vec<&str> = oauth_config.scopes.iter().map(|s| s.as_str()).collect();
oauth_state.start_authorization(&scopes, &redirect_uri, Some("Forge")).await?;

This path reads scopes from the user's OAuth configuration. But the mcp_auth() login path does not have access to this configuration -- it always uses &[].

Root Cause

Forge relies entirely on rmcp's automatic scope discovery in the mcp_auth() path. If the server's protected resource metadata (/.well-known/oauth-protected-resource/<path>) is not reachable or returns unexpected data, the fallback is empty scopes, causing the authorization server to issue a token with only default scopes (e.g., profile email).

Potential fixes:

1. Add a --scopes flag to forge mcp login to let users specify scopes
2. In the mcp_auth() path, read scopes from the MCP server's OAuth config in .mcp.json
3. Improve error reporting when scope discovery returns empty