Skip to content
OAuth Authentication

OAuth Authentication

Some MCP servers require OAuth 2.0 authentication to access third-party APIs on behalf of users. For example, a Dropbox MCP server needs a user’s Dropbox access token to read and write files. TeamWeb AI supports the OAuth 2.0 Authorization Code flow with PKCE for these servers.

How It Works

  1. An admin configures OAuth credentials (client ID, secret, endpoints) on the MCP server.
  2. An admin or user completes the OAuth consent flow to authorize TeamWeb AI.
  3. TeamWeb AI stores the access and refresh tokens (encrypted at rest).
  4. When the assistant calls a tool on that server, TeamWeb AI attaches the Bearer token automatically.
  5. Tokens are refreshed automatically before they expire.

Token Sharing Modes

Each OAuth-enabled MCP server is configured with one of two sharing modes:

ModeBehavior
SharedOne token for all users. An admin authorizes once and all assistants use that token.
Per UserEach user authorizes separately. Users are prompted inline in chat when they first use a tool that requires authorization.

Shared is best for service accounts or organization-wide access (e.g., a shared Dropbox folder). Per User is best when the server acts on behalf of individual users (e.g., accessing a user’s personal files).

Configuring OAuth

Navigate to MCP Servers > New MCP Server (or edit an existing one). Under the Authentication section, select OAuth 2.0.

Required Fields

FieldDescription
Client IDOAuth application client ID from the provider
Client SecretOAuth application client secret
Authorization URLProvider’s authorization endpoint (must be HTTPS)
Token URLProvider’s token endpoint (must be HTTPS)

Optional Fields

FieldDescription
ScopesSpace-separated OAuth scopes to request
Token SharingShared (default) or Per User
OAuth authentication requires an HTTP-based transport (SSE or Streamable HTTP). The stdio transport communicates via stdin/stdout pipes and cannot carry Bearer token headers.

Setting Up the OAuth Application

At the OAuth provider (e.g., Dropbox, Google, GitHub), create an OAuth application and configure the callback URL as:

https://your-teamweb-domain.com/oauth/callback

Make sure the PUBLIC_URL environment variable in your TeamWeb AI deployment matches the domain you register with the provider.

Authorizing

Shared Mode

After creating the server, visit the server’s detail page and click the Authorize button. You’ll be redirected to the OAuth provider to grant access. After approval, you’re returned to TeamWeb AI and the token is stored.

The detail page shows the token status:

  • Connected — Token is valid (with expiry date if applicable)
  • Expired — Token has expired and needs re-authorization
  • Not connected — No authorization has been completed yet

Per-User Mode

For per-user servers, users are prompted inline during chat when they first try to use a tool that requires authorization. The assistant provides an authorization link. After completing the flow in a browser tab, the user can return to their conversation and retry the tool.

Per-user OAuth servers are not available in non-interactive contexts (scheduled tasks, email replies, web triggers). These contexts cannot redirect a user to a browser. Use shared tokens for servers that need to work in automated workflows.

Token Refresh

TeamWeb AI handles token refresh automatically:

  • On-demand — When a tool call is made and the token is about to expire, a refresh request is sent to the provider before the tool call proceeds.
  • Proactive — A background task checks every 5 minutes for tokens expiring within 10 minutes and refreshes them preemptively.

If a refresh fails (e.g., the refresh token has been revoked), the last error is shown on the server’s detail page. For shared servers, an admin can click Authorize to re-authorize. For per-user servers, the user will be prompted again in chat.

Revoking Tokens

Click the Revoke button on the server’s detail page to delete all stored tokens. This is useful when rotating credentials or decommissioning a server. After revoking, re-authorization is required.

Credential Encryption

All MCP credentials (OAuth tokens, client secrets, environment variables, and headers) are encrypted at rest using AES-256-GCM. See Secret Storage for details on configuring the encryption key.