Skip to content

Connect an AI to your internal API with OAuth

Updated October 30, 2026 · Published October 30, 2026

To connect an AI to an internal API with OAuth, declare your API's OAuth application in the "Target API" tab of a Voozeo MCP server: each person then signs in with their own account, and every call reaches your API with that person's rights, never with a shared secret.

Why not a shared secret

By default, a server calls your API with one secret stored for everyone. That is simple, but every person who uses the AI acts with the same rights, and a leaked secret exposes everything it can reach. For an internal API, you often want the opposite: each person acts as themselves, and you keep the rights, the audit trail and the revocation your API already provides.

Voozeo MCP offers two ways to get there.

OAuth 2.0Forwarded by caller
Who signs inEach person, at your API provider, on the first callEach person, on the consent page of an OAuth gateway you operate
Where the credential livesThe token of the provider, stored encrypted by VoozeoNowhere: Voozeo forwards a header it receives and stores nothing
MCP keyNoneRequired, used by the gateway only
Best whenYour API provider supports OAuth 2.0 with the authorization code flowYou already run an OAuth gateway, or your API expects a custom token

Option 1: OAuth 2.0 with Voozeo as the broker

Voozeo plays the authorization server towards the AI and chains the sign-in to your API provider. The AI never receives the provider's token.

  1. At your API provider, create an OAuth application. Copy into it the "Callback URL to declare with your provider" shown in the tab, exactly as it is.
  2. In the "Target API" tab, choose "OAuth 2.0" and fill in the client ID, the client secret, the authorization URL and the token URL of the provider. If your OpenAPI file declares an OAuth 2.0 scheme, the URLs are prefilled as a suggestion; check them with your provider.
  3. Choose the scopes to request: ask for as few as your tools need. See OAuth 2.0.
  4. Add the server to your AI with its URL alone: there is no MCP key, no header. See servers using OAuth.
  5. On the first call, a Voozeo consent page shows the address that will receive the access, the provider and the scopes. The person clicks "Allow", signs in at your provider with their own account and accepts.

From then on, each tool call goes out with that person's token. Voozeo always uses PKCE with the provider, and it refuses private and internal addresses for the provider URLs. A server that uses OAuth accepts only OAuth: an old MCP key stops working.

Option 2: a credential forwarded by an OAuth gateway

If you already operate an OAuth gateway in front of your tools, or your API expects its own token, choose "Forwarded by caller" instead. Voozeo stores no secret: for each tool call, it forwards to your API the header it received, with the same name and value.

  1. In the "Target API" tab, choose "Forwarded by caller" and enter the header name (authorization by default).
  2. In the "Connection" tab, copy the URL that contains the key and declare it in your gateway. Do not give it to users: it carries the server key.
  3. The AI connects to the gateway. On its consent page, the person enters their own credential; the gateway adds it as the header on each call.

See per-user credentials with an OAuth gateway for the details and the limits, such as the quota shared by all users of the server.

Safeguards that apply to both options

  • Least privilege: request only the scopes your tools need, and expose only the tools the AI needs. See choosing and describing tools.
  • Revocation: on an OAuth 2.0 server, "Revoke all authorizations" disconnects every AI at once. Changing the authentication type, the client ID or the provider URLs does the same. A person can also withdraw access from their account at your provider. See active authorizations.
  • No token passthrough: the token of your provider is never given to the AI, and the token the AI holds is never sent to your provider.
  • Quota and log: every call counts toward the quota of the workspace, and appears in the call log without its arguments or results unless you turn on the diagnostic mode for that server.

Check before you share the server

  1. Test with your own account: ask the AI for something your account may do, then for something it may not. Your API must refuse the second.
  2. Open the call log and check the status of both calls. See call log.
  3. Revoke the authorizations and confirm that the AI has to sign in again.

Go further

Get started