Basically, the subject.
OAuth is the only MCP-native auth protocol that is defined in the specification. Vendors release new MCPs that are SSE-only and thus cannot be configured via an API key. And, using OAuth is more secure than the API key that has to be stored plaintext in the mcp.json config.
So, we’re losing this competition so far.
How it looks like in Claude: https://youtu.be/w-w37LWNcIk?t=88
So please, please, prioritize this auth approach support.
Yeah, this will be needed by many servers soon. Passing an API key in URL like some MCP providers do now is not safe.
Yeah this makes a ton of sense especially given the roll out of these servers (all using OAuth):
I tried to get the linear mcp server working, it crashes out since it cannot complete the flow
Hey Cursor team when do we get the oAuth support on Cursor client? It’s the recommended way in the spec and should be prioritized rn
It was released in the latest change log: MCP one-click install and OAuth support.
@nhalstead we’re working on Streamable HTTP servers with OAuth 2.0 DCR and we’re having issues with Cursor’s OAuth dynamic client registrations. It seems to be using redirect URIs with a private (native app) URI scheme that doesn’t follow RFC 7595, Section 3.8 recommendations: RFC 7595 - Guidelines and Registration Procedures for URI Schemes.
Some OIDC-compliant Authorization Servers strictly validate the URI scheme for native apps and expect it to use the domain name, expressed in reverse order, for security reasons (avoiding collisions and providing identification on the scheme owner), which doesn’t seem to be the case for Cursor.
Is there any reason why Cursor isn’t following the IETF recommendation. Are there any provisions in place to support this moving forward? We just want to know this to plan accordingly on patching our Authorization Server implementation to relax this security setting and allow for any URI scheme string (or at least add the one Cursor uses to a sort of allow list).
Best!