Default to S256 code challenge if not specified in authorization server metadata

[LucaButBoring]

• Removes duplicated upfront code challenge method validation for OIDC metadata
• Defaults to S256 code challenge if code_challenge_methods_supported is not present in AS metadata

Motivation and Context

This change makes metadata validation slightly more flexible by assuming S256 is supported as a code challenge method if the code_challenge_methods_supported field is not provided in AS metadata. This is the case for both Azure AD and Cognito, despite both supporting it.

This is caused by a point of ambiguity in RFC 8414 in which OIDC metadata is supported as valid OAuth metadata, but existing OIDC-specific clients (with strict validation) do not understand the union of OAuth and OIDC metadata and will reject it. This poses challenges for integration with OIDC authorization servers that cannot trivially add support for this on existing metadata documents, but nevertheless support S256 in practice.

If code_challenge_methods_supported is present, validation happens in the same manner as today, rejecting documents that do not declare support for S256.

How Has This Been Tested?

Adjusted unit tests and validated against a custom server using simpleOAuthClient.

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

#832

[pcarleton]

LGTM!