OAuth Architecture Simplification

[kavin-kr]

Problem

The current OAuth setup is a bit complex, especially in HTTP mode.

Proposed Changes

1. Google OAuth Desktop Credentials for stdio mode

Current: Users must create Google OAuth credentials to try the library.

Suggestion: Include default desktop credentials in the source code. Google's documentation allows this for desktop apps (localhost-only redirects). In STDIO mode, the MCP server will handle the OAuth flow, store the token locally, and refresh it. New users can try the MCP server immediately and don't need to create OAuth credentials.

---

2. HTTP Mode: Does tokens needs to be stored in MCP server?

Current: The server stores OAuth tokens and manages multi-user sessions. Even in OAuth 2.1 mode, the user token is stored on the server.

Suggestion: Use bearer tokens directly from Authorization headers. No server-side token storage. MCP clients already handle the OAuth flow and send tokens in headers (like GitHub/Linear MCPs). Eliminates token management complexity.

---

3. Is user_google_email parameter actually needed?

Current: Every tool requires the user_google_email parameter.

Suggestion: Looking at the Google API calls, most tools don't actually use the email parameter for the API requests themselves. The email seems to be used mainly for credential storage and session management. If the email isn't used in the actual API calls, why require it in every tool signature?

---

4. Is start_google_auth tool actually needed?

Current: The start_google_auth tool is available for manually initiating authentication.

Suggestion: Since MCP clients already handle the OAuth flow, is this tool actually needed?

---

This is a breaking change, and I may have missed other valid cases that led to the current design. I’m creating this issue as a place to discuss the idea.

I’m happy to contribute these changes if they align with the project’s goals.

Thanks.

[taylorwilsdon]

Thanks for the detailed submission! I don't think #1 is possible - there is no mechanism I'm aware of to create a generic oauth credential set that actually has the necessary APIs enabled since that's something that's scoped to your own GCP and Workspace environment. If you've seen that possible before, would love to learn more!

#2 is on the way today with WORKSPACE_MCP_STATELESS_MODE - will allow for easier cloud deployment on platforms that don't offer persistent storage.

#3 I'm with you in general, I wish we didn't need user_google_email but stdio doesn't work without it since there's no concept of an ongoing session. We already remove it from the docstring when it's not necessary (Oauth mode) via _remove_user_email_arg_from_docstring - I'd be very open to removing the param entirely if we can accomplish that in an elegant manner.

#4 Same as above, it's a necessity only for legacy modes. I am thinking that we can use the server registration filters to skip deploying in oauth2.1/stateless mode

[taylorwilsdon]

#189 has 2, 3 and 4 included!