Integrating Google OAuth for MCP SSE Connections in Cursor

Discussions
1

Hi everyone,

I’m facing an authentication challenge with our MCP integration in Cursor and would appreciate your insights.

We have an MCP server built with FastAPI that exposes our “chat” tool via SSE. For our web UI (powered by NextAuth), we rely on Google authentication to ensure the proper username and email context. However, when it comes to the MCP connection from Cursor, the usual Google OAuth flow isn’t triggering, leaving us without an authenticated user context on the server.

In essence, while our MCP server expects Google OAuth credentials (either via an external flow or token injection), Cursor’s MCP client currently appears not to support custom auth headers, token injection, or automatic redirection to a Google login page. We’re exploring options like:

  1. Pre-authentication: Running a one-time OAuth flow externally to obtain a token (or refresh token) that the server can use for subsequent MCP requests.
  2. Proxy/Wrapper: Setting up a proxy that injects the necessary auth headers into the SSE connection from Cursor.
  3. Awaiting Native Support: Looking for future enhancements in Cursor that might allow for an integrated OAuth flow or custom header/token support.

Has anyone successfully tackled this issue or have recommendations on integrating Google authentication with MCP in Cursor? Any pointers on workarounds or upcoming features would be greatly appreciated.

5 Likes
2

This is a pretty complex setup you’re working with. Currently, Cursor’s MCP implementation is fairly basic and doesn’t support OAuth flows or custom auth headers out of the box

Your best bet is probably going with the pre-authentication approach - having users authenticate once through your web UI to generate a long-lived token, then using that token in your MCP server implementation. You could store this in a config file that your MCP server reads

The proxy approach could work too, but adds more complexity to maintain. I wouldn’t wait for native support as this is a pretty niche use case that likely won’t be prioritized soon

Check out our MCP docs for the current implementation details: Cursor – Model Context Protocol

3

Thanks!

In regards to Native support, we did see that the MCP standard are busy thinking/wokring on an OAuth solution - see Authentication · modelcontextprotocol/specification · Discussion #64 · GitHub.

You believe perhaps Cursor will follow suit?

1 Like
4

If the GitHub tool which is listed in the docs supports the OAuth-based authentication in addition to the PAT-based authentication, it would be awesome as the Notion MCP tool already supports the OAuth-based authentication. In an enterprise, we don’t want employees to create their own PAT. That can increase security risks. By the OAuth-based authentication, we don’t have to manage GitHub personal access tokens.

5

hi, do you have the mcp server demo code that has implemented OAuth?

6

Same here. My MCP tool with google authentication works in Claude desktop/website but fail in Cursor. I don’t think the issue is in my side.

Checked Cursor – Deeplinks documents and not able to find any clue on this. Below is related msg in cursor MCP logs.

2025-06-06 10:20:54.175 [error] rver: Client error for command Incompatible auth server: does not support dynamic client registration

2025-06-06 10:20:54.176 [error] rver: Error connecting to SSE server after fallback: Incompatible auth server: does not support dynamic client registration

  • client version
    Version: 1.0.0 (user setup)
    VSCode Version: 1.96.2
    Commit: 53b99ce608cba35127ae3a050c1738a959750860
    Date: 2025-06-04T19:44:25.253Z
    Electron: 34.5.1
    Chromium: 132.0.6834.210
    Node.js: 20.19.0
    V8: 13.2.152.41-electron.0
    OS: Windows_NT x64 10.0.22631
7

After strugling with integrating our Oauth authorized hosted SSE MCP, we reverted to using npx+remote_mcp, which works kinda nice, but is not ideal from the user standpoint. We’re seeing more and more non-technical people using Cursor and installing node+npx is a needless hurdle for them.