[BUG] MCP OAuth Dynamic Client Registration: client_id is not persisted and strict RFC 9207 iss check breaks authorization #29620

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:

   ✕ 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:

   "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

Client Information

• CLI Version: 0.62.0
• OS: macOS (darwin arm64)
• Node.js: v26.3.0
• Package: @google/gemini-cli@0.62.0

Additional Context

• Related to RFC 9207 issuer enforcement discussed in MCP OAuth: RFC 9207 check rejects iss-less callbacks from servers that do not advertise authorization_response_iss_parameter_supported #29477.
• Related to DCR support requests in Support Oauth 2.1 DCR for MCP servers #29109 and [BUG] MCP oAuth2.1 Dynamic client registration fails #20990.