Change ProtectedResourceMetadata URI properties to strings and build resource strings directly

[Copilot]

Fix ProtectedResourceMetadata.Resource URI Normalization

This PR fixes an issue where using Uri type for the ProtectedResourceMetadata.Resource property and related URI properties caused unwanted normalization during JSON serialization/deserialization, which added trailing slashes to URIs like http://localhost:5000.

Changes

Protocol types

• Changed URI properties in ProtectedResourceMetadata from Uri?/List<Uri> to string?/List<string>
  • Resource, AuthorizationServers
• Added [StringSyntax(StringSyntaxAttribute.Uri)] attributes to URI string properties for better IDE support and validation
  • Resource, JwksUri, ResourceDocumentation, ResourcePolicyUri, ResourceTosUri
• Changed Clone() method to take string? instead of Uri? to avoid intermediate Uri creation and normalization

OAuth provider

• Modified ClientOAuthProvider.GetRequiredResourceUri() to return string
• Added NormalizeUri(string) overload with Uri.TryCreate validation
• Convert authorization server strings to Uri objects with error handling before passing to selector

MCP spec compliance

• Automatically derived resource URIs now trim trailing slashes per MCP authorization spec recommendation
• Updated McpAuthenticationHandler.HandleDefaultResourceMetadataRequestAsync() to build resource string directly using string interpolation, avoiding intermediate Uri objects
• Added IsDefaultPort() helper with case-insensitive scheme comparison to properly format URIs with/without port numbers
• Trim trailing slashes from path when building derived resource string
• Per MCP spec: implementations SHOULD consistently use URIs without trailing slashes unless semantically significant

Tests

• Updated ResourceMetadata_DoesNotAddTrailingSlash test to:
  • Not explicitly set resource (let it be auto-derived)
  • Manually verify PRM document doesn't contain trailing slash via HTTP GET
  • Actually authenticate with the client to ensure end-to-end flow works
• Updated ResourceMetadata_PreservesExplicitTrailingSlash test to:
  • Manually verify PRM document contains the explicit trailing slash via HTTP GET
  • Actually authenticate to verify explicit trailing slashes work
  • Use instance ValidResources property (no try/finally needed)
• Updated TestOAuthServer.ValidResources to only accept URIs without trailing slashes by default
• Changed ValidResources from static to instance property

Example

// Before: Uri constructor adds trailing slash
var metadata = new ProtectedResourceMetadata 
{ 
    Resource = new Uri("http://localhost:5000")  // Becomes "http://localhost:5000/"
};

// After: String preserves exact value, built directly without intermediate Uri
[StringSyntax(StringSyntaxAttribute.Uri)]
public string? Resource { get; set; } = "http://localhost:5000";  // Stays "http://localhost:5000"

// Clone now takes string to avoid normalization
var cloned = metadata.Clone("http://localhost:5000");  // No intermediate Uri, no normalization

// Resource strings built directly in handler
string derivedResource = $"{scheme}://{host}:{port}{path.TrimEnd('/')}";  // No UriBuilder

The [StringSyntax] attribute provides IDE intellisense and validation for URI strings while avoiding the normalization issues that come with the System.Uri type. Building resource strings directly without intermediate Uri objects ensures no unwanted normalization occurs.

Fixes #1122

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[halter73]

I think using Uri in ProtectedResourceMetadata was a mistake since it does unnecessary normalization during deserialization that prevents us from seeing the original value we are supposed to round trip.

This should fix #1122.

[halter73]

@copilot Can we just remove the properties from ProtectedResourceMetadata that we don't use/read like ResourcePolicyUri and any others? Please remove any unused non-URI properties too. We're not trying to create a generic OAuth library. We only need the properties necessary to complete client OAuth authentication. We can always add the properties back later if we need them without breaking API changes.

[Copilot]

@copilot Can we just remove the properties from ProtectedResourceMetadata that we don't use/read like ResourcePolicyUri and any others? Please remove any unused non-URI properties too. We're not t...

Done. Removed all unused properties from ProtectedResourceMetadata. Only kept the properties necessary for OAuth client authentication: Resource, AuthorizationServers, ScopesSupported, and the internal WwwAuthenticateScope. (f18c391)

[halter73]

@stephentoub Can you reapprove this? It's exactly as you saw it last.

I reverted the property removals I asked copilot to make, because I noticed/remembered that we use the same DTO to produce the PRM on the server, so it is nice to have all those properties like ResourceDocumentation there. That's why we included them in the first place of course.

[FICTURE7]

This should fix #1122.

An alternative would be to use Uri.OriginalString when passing the resource indicator in the token/authorize requests. Unless there is some edge cases am unaware of.

[halter73]

Thanks @FICTURE7. I considered that after seeing it in your HackPrmJsonType() method in #1122 which I'm sure @eiriktsarpalis will appreciate. I think using string is the right move though. We do the same thing for other JSON-serialized URIs like ReadResourceRequestParams.Uri where we pass the string along to application code. The main motivation is to avoid breaking scenarios that could work with other SDKs because we're being too strict.

csharp-sdk/src/ModelContextProtocol.Core/Protocol/ReadResourceRequestParams.cs

Lines 18 to 20 in 27b5eb8

	[JsonPropertyName("uri")]
	[StringSyntax(StringSyntaxAttribute.Uri)]
	public required string Uri { get; set; }

Since we do validate that the ProtectedResrouceMetadata.Resource matches the Uri we pass to the HttpClient to connect to the MCP server, I can see the argument that this could stay a Uri, but I still think it's more consistent to use strings for URIs for all of our public JSON-serializable types.

That does make me notice we used [StringSyntax(StringSyntaxAttribute.Uri)] for those though. @copilot can you add the [StringSyntax(StringSyntaxAttribute.Uri)] where appropriate.

[Copilot]

Thanks @FICTURE7. I considered that after seeing it in your HackPrmJsonType() method in #1122 which I'm sure @eiriktsarpalis will appreciate. I think using string is the right move though. We do the...

Done. Added [StringSyntax(StringSyntaxAttribute.Uri)] to all URI string properties in ProtectedResourceMetadata: Resource, JwksUri, ResourceDocumentation, ResourcePolicyUri, and ResourceTosUri. Note that AuthorizationServers is a List<string> so the attribute can't be applied directly to the list property (it would apply to the list itself, not the string elements). (45bdb39)