Fix Azure AD v2.0 compatibility by filtering unsupported 'resource' parameter

[nbaju1]

Description

Problem

The Azure provider fails when MCP clients send the resource parameter (from RFC 8707 - OAuth 2.0 Resource Indicators) because Azure AD v2.0 endpoints don't support this parameter. Users get the error:

The "resource" request parameter is not supported

Root Cause

The OAuthProxy base class forwards all OAuth parameters including resource if present:

# oauth_proxy.py line ~444
if params.resource:
    query_params["resource"] = params.resource

While this is correct per OAuth 2.0 specs, Azure AD v2.0 specifically rejects this parameter. Azure AD v2.0 uses scopes (like api://app-id/.default) to determine the resource/audience instead.

Solution

Override the authorize method in AzureProvider to filter out the resource parameter before forwarding to Azure AD v2.0. This maintains compatibility with both:

• MCP clients that send the resource parameter (following RFC 8707)
• Azure AD v2.0 which doesn't support it

Changes

• Added authorize method override in AzureProvider class
• Added imports for AuthorizationParams and OAuthClientInformationFull
• Added debug logging when filtering out the resource parameter

Backwards Compatibility

This change is fully backwards compatible. Existing Azure provider users will see no change in behavior unless they were experiencing the "resource parameter not supported" error.

AI generated code and PR description with Claude Opus 4.1

Contributors Checklist

• My change closes Microsoft Entra OAuth Error: The 'resource' request parameter is not supported. #1846
• I have followed the repository's development workflow
• I have tested my changes manually and by adding relevant tests
• I have performed all required documentation updates

Review Checklist

• I have self-reviewed my changes
• My Pull Request is ready for review

---

[nbaju1]

Failed test seems unrelated.

[jlowin]

Thanks for raising @nbaju1 and your approach makes sense -- my only hesitation is mutating the params object could have other consequences that would be difficult to diagnose. Would it be possible to instead create a shallow copy of params with resource=None (model_copy() might do it easily) and pass that to the super method instead?

[nbaju1]

I added this fix to #1891. Can either close this PR, or fix the eventual merge conflict in that PR if this gets merged.

[jlowin]

Ok, let's focus on #1891 and close this PR. thank you!