Add OAuth Support for MCP Connections in mcp-client-chatbot

[vignesh69420]

Add OAuth Support for MCP Connections (Outlook, Teams, Gmail, ServiceNow, Confluence, etc.)

Description
Problem Statement
Currently, mcp-client-chatbot's MCP connection UI only supports basic authentication methods, requiring users to manually enter credentials (username/password or API tokens) for each connection. This creates several issues:

Security Concerns: Sensitive credentials are being entered directly into the UI
Poor User Experience: Users need to re-enter credentials for each session
Limited Enterprise Integration: No support for modern authentication standards used in enterprise environments
Credential Management: No secure way to store or refresh tokens
Specific Examples
ServiceNow MCP: Currently requires entering username/password or passing them as URL parameters
Confluence/JIRA MCP: Requires API tokens to be manually entered or passed in URL parameters
Other OAuth-capable services: Cannot leverage their built-in OAuth capabilities
Proposed Solution
Implement OAuth support for MCP connections in mcp-client-chatbot, with the following features:

OAuth Flow Integration: Add support for standard OAuth 2.0 authorization code flow
Token Management: Securely store and refresh OAuth tokens
Connection Persistence: Allow users to maintain authenticated connections across sessions
UI Improvements: Add OAuth login buttons for supported services
Configuration Options: Allow developers to configure OAuth settings in the mcp-client-chatbot config

[linear]

MCP-26 Add OAuth Support for MCP Connections in mcp-client-chatbot

[cgoinglove]

Hello,
I’m aware that this is something that needs to be done eventually.
However, there are currently no concrete plans regarding when or how it will be carried out.
I’ll take the time to review it carefully.

[vignesh69420]

Thank You

[Noahunterweger]

Please add this i need this too.

[Noahunterweger]

Is it possible to get this before ai sdk v5?

[brrock]

I'll try and research it. It isn't well documented

[cgoinglove]

ok i'll ckeck it this weekend

[Noahunterweger]

OAuth2 Flow with Dynamic Client Registration (Technical Overview)

1. Discovery Phase

The client (ExampleApp) begins by retrieving OAuth2 configuration metadata from your server (OAuth Proxy):

• GET /.well-known/oauth-protected-resource
  → Returns metadata including the authorization server(s) in use.

• GET /.well-known/oauth-authorization-server
  → Returns standard OAuth2 metadata (token endpoint, authorization endpoint, supported grant types, PKCE support, etc.).

This step enables the client to dynamically discover how to interact with the OAuth server without hardcoding endpoints.

---

2. Dynamic Client Registration

• POST /register to OAuth Proxy
  → Registers ExampleApp as an OAuth client.

• Response includes:

  • client_id
  • Optionally client_secret (depending on client type)
  • Redirect URIs
  • Allowed scopes, etc.

This allows your OAuth Proxy to track registered clients and issue tokens accordingly.

---

3. Authorization Code Flow (PKCE)

The client initiates the OAuth authorization flow with PKCE:

• ExampleApp generates:

  • code_verifier
  • code_challenge = BASE64URL(SHA256(code_verifier))

• User is redirected to your proxy’s /oauth/authorize endpoint:

  • Includes parameters: response_type=code, client_id, redirect_uri, scope, state, and code_challenge.

• The OAuth Proxy stores the redirect URI and PKCE details, then redirects the user to the actual upstream OAuth provider (e.g., Google, GitHub).

---

4. User Authentication and Consent

• User authenticates with the OAuth provider and grants the requested scopes (e.g., access to user profile, data, etc.).
• Upon success, the OAuth provider redirects the user back to the client’s redirect_uri with an authorization code and state.

---

5. Authorization Code Callback

• The client receives the authorization code via its registered callback URL:

  GET /auth_callback?code=abc123&state=xyz
  

• It uses this code to request tokens.

---

6. Token Exchange

• ExampleApp sends the code to your OAuth Proxy:

  POST /oauth/token
  grant_type=authorization_code
  code=abc123
  code_verifier=...
  client_id=...
  redirect_uri=...
  

• The OAuth Proxy forwards the request to the upstream OAuth provider’s token endpoint.

• If valid, the provider returns an access_token (usually a JWT).

• The OAuth Proxy returns this access token to the client.

---

7. Authenticated API Access

Once the access token is issued, ExampleApp can access secured resources by including the token in requests to your OAuth Proxy:

• Example:

  POST /mcp/some_tool
  Authorization: Bearer <access_token>
  

• The OAuth Proxy validates the token:

  • Either by decoding it (if self-contained JWT) or
  • Via POST /introspect to the OAuth provider.

• If valid and active, the proxy performs the requested operation (e.g., forwards API calls to external services using the user’s token).

---

8. Repeated API Calls

All subsequent tool or API calls use the same access token until it expires. The proxy validates the token on each request and ensures it still grants access.

[brrock]

https://github.com/dzhng/mcp-client-auth is the only sane way of doing it @cgoinglove docs seem nice

[brrock]

Does anyone know anything about this because we would be sure to accept a PR

[Noahunterweger]

i'm currently working on a prototype that is very unstable