Skip to main content
Connector credentials are stored encrypted and injected at the host boundary. The model that calls the tool never sees them.

​
Three shapes

That is the full set. A REST connector takes None or Bearer; a registry MCP connector takes None or Bearer; only a Custom MCP connector can use OAuth.
There is no separate “Basic auth” or “API key header” auth type. An API that wants its key in a custom header — X-API-Key, X-Auth-Token — is configured through the connector’s common headers, which are stored encrypted like any other credential.

​
Bearer

One field: the token. Stored as ciphertext. Right for the large majority of modern REST APIs — anything documented as “send your key as a bearer token”.

​
OAuth 2.1

Available on Custom MCP connectors. The authorization and token endpoints are discovered from the MCP server’s own URL rather than entered by hand, so there is no provider form to fill in. Then authorize. The Portal walks the redirect, the code exchange happens server-side, and the resulting token set is stored encrypted. Refresh happens automatically under a distributed lock, so concurrent calls do not each try to refresh. A connector configured for OAuth with no token yet shows as Needs auth.

​
MCP connector credentials

MCP connectors use the same auth config as the rest: none or a bearer token, plus optional encrypted headers on the transport. A Custom MCP connector can also use OAuth, including dynamic client registration — while that registration is in flight the connector shows as Needs auth.

​
Storage

Every secret field is AES-256-GCM ciphertext with a nonce, base64-encoded. That covers bearer tokens, OAuth client secrets, OAuth access and refresh tokens, and connector common headers. Use an https endpoint so the hop to the upstream service is encrypted. An http URL is accepted, and nothing about it is private.

​
Rotation

A connector’s configuration is fixed once it is created — after that you can change its name, description, and whether it is active, but not its credentials.
  • Bearer — create a replacement connector with the new token, rebind, then delete the old one.
  • OAuth — access tokens refresh on their own. Re-authorize only if you need different scopes or the upstream revoked the grant.

​
Handling secrets well

  • Grant the narrowest scope that works. Read-only where read-only is enough.
  • One connector per credential, so revoking one does not take down the others.
  • Prefer a connector over passing a token to HTTP Client. HTTP Client has no credential store, which means the secret would have to reach the model.
  • Deleting the connector removes its stored credentials.

​
Next