oauth: validate discovered OAuth endpoints before login

[Ashwinhegde19]

Version / branch / commit

main at commit 3c81fea

OS and environment

macOS 26.5.2 / darwin arm64 / Go 1.26.4

Summary

Configured OAuth endpoints are rejected when they use a non-HTTPS, non-loopback URL, but endpoints learned from OAuth/OIDC discovery are merged without the same validation. That lets discovery metadata downgrade the authorization, token/device, or MCP registration endpoint safety after the initial provider config has already passed validation.

This affects both the provider OAuth flow and the MCP OAuth flow because MCP delegates discovery to internal/oauth and then uses the returned metadata.

Steps to reproduce

1. Configure an OAuth provider or MCP OAuth server using an issuer/discovery URL.
2. Serve discovery metadata from that issuer with an insecure discovered endpoint, for example:

{
  "issuer": "http://127.0.0.1:12345",
  "authorization_endpoint": "http://evil.example/authorize",
  "token_endpoint": "http://127.0.0.1:12345/token"
}

3. Start the loopback login flow.
4. The login flow builds and opens an authorization URL beginning with http://evil.example/authorize?.

I verified this locally with temporary tests against both internal/oauth.Manager.Login and the MCP OAuth resolver/authorization URL path. The fake browser opener received a URL starting with http://evil.example/authorize?.

Expected behavior

Discovered OAuth endpoints should be validated before being merged or used. A non-HTTPS, non-loopback authorization_endpoint, token_endpoint, device_authorization_endpoint, or MCP registration_endpoint should be rejected with the same endpoint-safety rule used for configured endpoints.

Actual behavior

Configured endpoints pass through validateTokenEndpoint, but discovery metadata is merged without revalidation:

• internal/oauth/providers.go validates configured endpoints.
• internal/oauth/manager.go merges discovered provider endpoints into the config.
• internal/mcp/oauth.go merges discovered MCP OAuth metadata.
• internal/oauth/flow.go only parses the authorization endpoint before building the browser URL.

As a result, discovery metadata can silently downgrade the login flow to an insecure authorization URL.

Notes

I did not find an existing issue or open PR covering this exact validation gap.