fix(auth): oauth metadata discovery

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

[glicht]

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

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
• [ x I have added or updated documentation as needed

Additional context

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

[glicht]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

[wdawson]

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

[tanish111]

@glicht tested locally?

[tanish111]

@alexhancock can you also look into it issue and fix once?

[glicht]

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

[alexhancock]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

[alexhancock]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

[glicht]

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

[wdawson]

@wdawson@tanish111@glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

[alexhancock]

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!