rahatHSL
### What happened? When authenticating with an MCP server using OAuth 2.0 / 2.1 via `/mcp auth <server>`, Dynamic Client Registration (RFC 7591) and the callback handling encounter two interrelated issues: 1. **Dynamic Client Registration credentials are not persisted across sessions:** When connecting to an MCP server without a pre-configured `clientId`, Gemini CLI successfully performs Dynamic Client Registration against the server's `registration_endpoint` using an ephemeral loopback redirect URI (e.g. `http://localhost:<random-port>/oauth/callback`). However, the resulting `client_id` and registration details are kept in memory only (`config.clientId = clientRegistration.client_id`) and are never saved to configuration (`settings.json`) or persistent token/client storage. Consequently, every subsequent `/mcp auth` invocation or reconnection triggers a brand new DCR call, registering duplicate client records on the authorization server. 2. **Unconditional RFC 9207 `iss` check causes dynamic registration to fail:** During the authorization callback, Gemini CLI strictly rejects responses without an `iss` parameter: ```text ✕ Failed to authenticate with MCP server '<server>': Missing "iss" parameter in authorization response per RFC 9207 ``` In `packages/core/src/utils/oauth-flow.ts`, `startCallbackServer` validates `expectedIssuer` which is populated from discovery metadata. Gemini CLI unconditionally rejects missing `iss` even when the Authorization Server metadata does not advertise `authorization_response_iss_parameter_supported: true`. Per RFC 9207 §2.4 and MCP Specification (2026-07-28), clients should proceed when `authorization_response_iss_parameter_supported` is absent or false. ### What did you expect to happen? 1. When Dynamic Client Registration succeeds, the registered client information (`client_id`, `client_secret` if applicable, registration URI) should be cached or persisted so the client is reused rather than re-registering on every authentication attempt. 2. The RFC 9207 `iss` parameter check should respect `authorization_response_iss_parameter_supported: true` in the authorization server metadata. If absent or false, the client should not abort with `Missing "iss" parameter in authorization response per RFC 9207`. ### Steps to Reproduce 1. Configure an MCP server in `~/.gemini/settings.json` that uses dynamic discovery with an RFC 7591 registration endpoint: ```json "mcpServers": { "my-server": { "url": "https://staging.mcp.example.com/mcp", "type": "http" } } ``` 2. Run `/mcp auth my-server`. 3. Observe: - DCR executes and creates a new client. - If the callback does not carry `iss`, it fails with `Missing "iss" parameter in authorization response per RFC 9207`. - Re-running `/mcp auth my-server` creates another new client via DCR rather than reusing the previous registration. ### Client Information <details> <summary>Client Information</summary> - **CLI Version:** 0.62.0 - **OS:** macOS (darwin arm64) - **Node.js:** v26.3.0 - **Package:** `@google/[email protected]` </details> ### Additional Context - Related to RFC 9207 issuer enforcement discussed in #29477. - Related to DCR support requests in #29109 and #20990.