Connections (OAuth apps and MCP Gateway)
Register MCP servers and OAuth apps for your organization in one place — admins register them, every member connects their own account, and the gateway authenticates on the workspace's behalf.
Connections is the single page in the Kimchi console where your organization sets up the external services that remote work can reach: MCP servers and OAuth apps. Admins register them; everyone connects their own account.
When a remote workspace needs to talk to an external service — an MCP server, GitHub, Atlassian, or any OAuth-protected API — it goes through the gateway, which authenticates on the workspace's behalf using the connections your organization registered. You never paste a token into a prompt, a setup script, or a file the agent can read.
The page has two tabs:
| Tab | What it holds |
|---|---|
| MCP servers | MCP servers your organization can reach through the MCP Gateway, and how each one authenticates |
| OAuth apps | Third-party OAuth apps registered for your organization, used for per-member sign-in |
Open the Connections page
In the Kimchi console, open the Connections page. It lives in the Remote Workspaces group of the sidebar, under Credentials.
The page appears only when Connections is enabled for your organization. If you do not see it in the sidebar, contact your organization administrator.
How authentication works
Every connection uses one of two authentication models:
Every member signs in with their own account at the provider. Access follows the provider permissions of each person, and workloads act with that user's token. This model is backed by an OAuth app registered on the OAuth apps tab.
Prefer this option over a static shared key: every request carries the signer's own token, so access always matches that person's actual provider permissions, and each member can disconnect their own account without affecting anyone else — there is no shared secret to rotate across the organization.
Shared credentials — one API key, bearer token, login, or OAuth client-credential pair is shared by everyone using the server through the gateway.
In both models the gateway attaches the credential to requests as they leave the workspace. Credential values are write-only: after you create a connection, the values cannot be read back from the console.
Register an OAuth app
Registering an OAuth app makes a provider available for per-member sign-in. Connecting stays personal: every member — including you — signs in with their own account.
Open the registration form
On the OAuth apps tab, select Register OAuth app.
Choose a registration method
Pick Discover (default) or Manual at the top of the form.
Register by discovery
Enter a Name and the provider's MCP server URL. If the provider supports automatic registration, Kimchi discovers its OAuth endpoints and creates the app for you — no client ID or secret to manage. Scopes are optional; leave them empty to request whatever the provider advertises. If discovery is not supported for the provider, switch to manual registration instead.
Register manually — create the app on the provider's side
In manual mode, first create the OAuth app in your provider's settings and allow the callback URL shown on the form as an allowed redirect URI.
Register manually — paste the app's details
Back in the form, enter the Client ID and Client secret from the provider, plus its Authorize URI and Token URI.
Set scopes, host patterns, and the header pattern
Finish with the fields both methods share:
- Scopes — space- or comma-separated list of scopes to request.
- Host patterns — required. Space- or comma-separated lowercase hosts or wildcards, for example
api.github.comor*.example.com. These decide which hosts the app's token is used for. - Header pattern (manual mode only) — how the token is attached to requests.
{}is replaced with the access token; leave empty to use the defaultBearer {}.
Register the app
Select Discover & register or Register OAuth app. The app appears in the OAuth apps list, marked with a DCR badge when it was registered through discovery.
Add an MCP server
Open the create form
On the MCP servers tab, select Add MCP server.
Name the connection and set the URL
Enter a Name, for example Atlassian MCP, and the MCP server URL — an absolute https:// address, for example https://mcp.example.com/mcp.
Choose how users connect
Pick one of the two authentication models: Each member connects individually (OAuth) or Shared credentials.
Pick an OAuth app — per-member sign-in
If you chose per-member OAuth, select the backing app from the OAuth app list. Only apps registered on the OAuth apps tab appear here; if none are registered yet, follow Register an OAuth app first.
Enter a shared credential — shared sign-in
If you chose shared credentials, pick the credential type and fill in its fields:
| Credential type | What to provide |
|---|---|
| API key / token header | Header name, for example Authorization, and the header value |
| Bearer token | The token |
| HTTP basic auth | Username and password |
| OAuth client credentials | Client ID, client secret, and optionally a token URI |
For OAuth client credentials, the token URI is optional: when left empty, the gateway derives it from the MCP server itself, for example through OIDC discovery.
Create the connection
Select Create connection. The server appears in the MCP servers list.
The authentication type of an MCP server connection cannot be changed later. To use a different type, delete the connection and create it again.
Connect your account
Registering an OAuth app does not sign anyone in. Each member connects their own account:
- On the OAuth apps tab, apps you have not signed in to show a Connect button. Select it, complete the provider's sign-in in the browser, and the app shows a Connected status.
- On the MCP servers tab, connections that use per-member OAuth show the state in the Authentication column: a check mark when you are signed in, or a cross icon that starts the sign-in flow when you are not.
To revoke your own sign-in, select Disconnect from the app's ⋯ menu on the OAuth apps tab. Your token stops being used immediately; other members are not affected.
Status indicators
| Indicator | Meaning |
|---|---|
| Connected (teal dot) | Your account is signed in at the provider |
| Error (red dot) | Your sign-in state reported an error — select Connect to sign in again |
| Cross icon in the Authentication column | You have not signed in to this MCP server's backing app yet — select it to start the sign-in flow |
Edit or delete a connection
Use the ⋯ menu on any row:
- MCP servers — select Edit to change the name, server URL, or credential values. Leave a credential field empty to keep its current value; enter a new value to rotate it. Select Delete to remove the server; requests to it stop being authenticated through the gateway.
- OAuth apps — select Edit to update the registration, including the client secret. Select Delete to remove the app from the organization.
Who can do what
| Capability | Who |
|---|---|
| Register, edit, and delete MCP servers and OAuth apps | Members with administrator permissions |
| View both tabs and connect or disconnect their own account | Every member who can open the page |
Tabs are shown according to your permissions. If you can open Connections but a tab is missing, you do not have permission to view that kind of connection — contact your organization administrator.
See also
- Create and Use a Remote Workspace — Step-by-step developer journey: create a workspace from a template, connect, and reconnect later.
- Remote Credentials — Store a static token once and inject it into outbound requests without exposing it to the agent.
- Workspace Templates — Reusable workspace configurations, including setup scripts.
- User Roles — Manage roles and permissions in your organization.
Updated 5 days ago