Client/Server Auth flow (authorized clients)

[Ejb503]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

I've built a Native Android and Native iOS MCP Client and am looking to integrate this with modern servers following latest spec.

In the auth flow (using https://mcp.sentry.dev/sse) as an example, I can implement my client to handle the discovery and oauth handshake, however the oauth flow cannot (by design) work unless my redirect url is allowed by the oauth server itself.

In practice, this means that the oauth flow in the spec is impractical, unless every supported client and every compliant server manually implement this trusted pattern.

Is there, or should there be, a discovery mechanism for servers to trust "all" mcp clients, from the perspective of large oauth hosts (sentry.io being the first example of theoretically thousands), it seems there should be some mechanism.

What is the recommendation here? (Is trusted redirects * even theoretically possible or safe?)

[Ejb503]

Link to github issue on sentry mcp getsentry/sentry-mcp#214 (comment)

[Ejb503]

What is think I'm basically interested in is a formalised standard for dynamic registration that would enable a client to reliably register a compatible client where permitted...

If every server rolls their own registration flow, makes it hard to scale clients...

https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization

2.4 Dynamic Client Registration
MCP clients and servers SHOULD support the OAuth 2.0 Dynamic Client Registration Protocol to allow MCP clients to obtain OAuth client IDs without user interaction. This provides a standardized way for clients to automatically register with new servers, which is crucial for MCP because:

Clients cannot know all possible servers in advance
Manual registration would create friction for users
It enables seamless connection to new servers
Servers can implement their own registration policies
Any MCP servers that do not support Dynamic Client Registration need to provide alternative ways to obtain a client ID (and, if applicable, client secret). For one of these servers, MCP clients will have to either:

Hardcode a client ID (and, if applicable, client secret) specifically for that MCP server, or
Present a UI to users that allows them to enter these details, after registering an OAuth client themselves (e.g., through a configuration interface hosted by the server)

[Ejb503]

https://curity.io/resources/learn/using-dynamic-client-registration/ closed, skill issue