MCP Server Authentication: Keys, Tokens and Per-User OAuth

MCP server authentication decides two things: who may call your MCP server, and how that server signs in to the API behind it. GetMCP handles both from one screen. You store an API key, bearer token or username and password once, pass each person’s own credential through, or let every user sign in to their own account with OAuth.

This guide is for anyone turning a REST API into an MCP server with GetMCP: a SaaS team exposing its product to Claude, an agency wiring a client’s CRM into Cursor, or a developer connecting an internal tool. You will learn what each option does, which one fits your API, and the gotchas the code enforces.

What is MCP server authentication in GetMCP?

Every GetMCP server sits between an AI client and an API. That gives authentication two sides. The inbound side is what an MCP client such as Claude or Cursor must present to reach your server. The outbound side is the credential GetMCP attaches when a tool calls the upstream API.

Both live on the server’s Authentication tab, which has up to three sections:

• Server-stored API credential: the key GetMCP itself attaches to every upstream call. Connected AI clients never see it.
• Client Authentication: who may connect to this MCP server and what they must present. Choose None, Bearer Token, API Key, Basic Auth or OAuth 2.0.
• Test Credentials: a credential used only by the admin’s Test Tool button and the chat playground, shown when Client Authentication is set to a passthrough mode.

Authentication is set per server, and every tool on that server shares it. If two groups of tools need different credentials, put them on two servers.

How it works

When a tool runs, GetMCP builds the HTTP request from the tool’s configuration, then decides which credential to attach. The order is fixed in code:

1. A server-stored credential wins. If one is saved, GetMCP attaches it to the upstream request, whatever the client sent. It replaces the incoming Authorization header rather than forwarding it.
2. No stored credential and Client Authentication is None: the request goes upstream with no credential, which suits public APIs.
3. OAuth 2.0: GetMCP attaches the upstream token of the person who signed in, so each user reaches the API as themselves.
4. Bearer, Basic or API Key: GetMCP forwards the credential the MCP client sent, in the format the server is configured for. The upstream API does the real check.

To set it up, open your server, go to the Authentication tab and work top to bottom.

1. Under Server-stored API credential, pick a Credential Type: None — the API is public, Bearer Token, API Key or Basic (username + password).
2. For an API key, set the Header / Param Name (for example X-API-Key) and the Location: Header or Query Parameter.
3. Paste the key, token, or username and password, then click Save credential. This saves on its own and does not change Client Authentication.
4. Under Client Authentication, choose who may connect, then click Save Authentication.

Once saved, the secret is never shown again. The field reads “stored — leave blank to keep”, so you can update the header name without retyping the key. Stored credentials are encrypted on your server.

Key options and settings

Option	What it does
Credential Type: Bearer Token	Sends Authorization: Bearer <token> on every upstream call.
Credential Type: API Key, Header	Sends the key in the header you name. The incoming Authorization header is stripped so the client’s token never leaks upstream.
Credential Type: API Key, Query Parameter	Appends name=value to the request URL.
Credential Type: Basic	Builds Authorization: Basic from the username and password at request time.
Client Authentication: None	The endpoint is public: anyone with the URL can call the tools. Fine for testing; prefer OAuth beyond that.
Client Authentication: Bearer, API Key, Basic	Passthrough. GetMCP checks that a credential is present and forwards it; your API validates it.
Client Authentication: OAuth 2.0	Each user signs in to their own account at an identity provider you configure. Tool calls use that user’s token.
Test Credentials	Used only by the Test Tool button and the chat playground, never sent to or seen by connected MCP clients.

The per-user OAuth broker

Choose OAuth 2.0 when each person should use their own account, for example their own Google or GitHub login. You register an OAuth app with that provider and fill in five fields: Authorize URL, Token URL, Client ID, Client Secret and Default Scopes. The tab also shows an Authorized Redirect URI ending in /oauth/callback, which you paste into the provider’s app settings.

When a user connects, their MCP client is sent to the provider’s consent screen. GetMCP stores that user’s upstream token, encrypted, next to the MCP token it issues them. Your client ID and secret only start the sign-in; they are never used to call the API. The Client Secret is encrypted at rest and never exposed to MCP clients.

All four of Authorize URL, Token URL, Client ID and Client Secret are required. Until they are filled, the tab shows a “No identity provider configured” notice and clients cannot authorize. The inbound half of this flow, where GetMCP issues tokens to MCP clients, is covered in the inbound security guide linked below.

Choosing the right MCP server authentication pattern

The Authentication tab answers “Which section do I need?” with three cases, and most servers fit one of them:

• Your API needs one key, and you hold it. Enter it as the server-stored credential. Leave Client Authentication on None or OAuth.
• Each person should use their own account. Skip the stored credential and choose OAuth under Client Authentication.
• Each connecting client should bring its own key. Skip the stored credential and choose API Key, Bearer or Basic. Nothing is stored; the client’s credential is passed through on every call.

Use cases

Give a support team read access to a helpdesk with one shared key

Acme’s support lead stores the helpdesk API key once as an API Key credential in the X-API-Key header. Agents connect Claude and ask about open tickets; nobody ever sees the key.

Claude → GetMCP (stored API key) → Helpdesk API

Let each customer use their own API token in a SaaS integration

Northwind publishes an MCP server for its customers. Client Authentication is Bearer, so each customer puts their own Northwind token in their MCP client config. GetMCP forwards it, and Northwind’s API applies that account’s permissions.

Cursor (customer token) → GetMCP (passthrough) → Northwind API

Connect a WooCommerce store with an Application Password

WordPress Application Passwords are HTTP Basic auth. Store the username and Application Password as a Basic credential, and every tool on the server can call the store’s REST API with that user’s permissions. Use a dedicated user whose role allows only what the tools need.

Claude → GetMCP (Basic) → WooCommerce REST API

Let every marketer reach their own Google data

An agency registers one Google OAuth app and sets the server to OAuth 2.0 with the scopes the tools need. When Priya Sharma connects, she approves Google’s consent screen and her tool calls run with her token; Yuki Tanaka’s run with his.

Claude → OAuth sign-in (Google) → GetMCP (per-user token) → Google API

Expose a public API with no keys at all

Weather, currency and open-data APIs often need no credential. Set Credential Type to None and keep the tools read-only, so a public endpoint can only look things up.

AI client → GetMCP → public API

Test against a sandbox while users hit production

With Client Authentication on API Key, users send their own production keys. You put a sandbox key under Test Credentials, so the Test Tool button and the chat playground exercise the tools without touching live data.

Test Tool → GetMCP (test credential) → sandbox API

Let an AI assistant draft the server, then add the key yourself

When you build a server with Manage with AI, the assistant describes the connection but leaves the credential as a placeholder. The Authentication tab flags it with a “Still a placeholder” notice, and upstream calls fail until you enter the real key.

AI drafts server → you paste the key → tools go live

Tips and gotchas

• A stored credential turns off passthrough. With a server-stored credential saved, Bearer and Basic client modes refuse every request with “This server does not accept passthrough credentials.” Otherwise anyone could send any string and spend your key. API Key mode then accepts only keys issued by GetMCP.
• Passthrough is a presence check. In Bearer, Basic or API Key mode with no issued keys, GetMCP does not validate the credential itself; it forwards it and your API is the gate. The tab says so in an amber notice.
• Test Credentials can hide a real problem. A key that lives only in Test Credentials keeps Test Tool green while real clients fail. If you hold the key, it belongs in Server-stored API credential.
• OAuth plus a stored credential sends the stored one. A saved server credential wins for every client mode, OAuth included, so per-user tokens are only used when no stored credential is saved.
• With no test credentials, Test Tool uses the stored credential, so it exercises the same auth a production call would.
• A credential that can’t be decrypted stops the call. If your site’s security keys change, GetMCP returns an error asking you to re-enter the credential instead of calling the API unauthenticated.
• Exports leave secrets behind. A server export carries the auth shape, not the credentials. Re-enter them after importing.

Rule of thumb: if you hold the key, store it. If your users hold the keys, pass them through. If your users have accounts at a provider, use OAuth.

Related features

• Inbound security with OAuth 2.1 and API keys: control who can connect to the endpoint.
• Connection variables: put account subdomains and data-centre codes into endpoints without hardcoding them.
• Chat playground: test tools with a real model before anyone connects.
• MCP authentication explained: the concepts behind API keys, bearer tokens and OAuth 2.1.

FAQ

How do I add an API key to an MCP server?

Open the server’s Authentication tab, choose API Key under Server-stored API credential, set the header or query parameter name, paste the key and click Save credential. GetMCP attaches it to every tool call on that server. Connected AI clients never see it.

Are my API credentials stored securely?

Stored credentials, OAuth client secrets and per-user upstream tokens are encrypted on your own server. The admin screen never echoes a saved secret back; it only shows that one is stored. Credentials are also left out of server exports.

Can each user sign in with their own account?

Yes. Set Client Authentication to OAuth 2.0 and configure the identity provider’s Authorize URL, Token URL, Client ID and Client Secret. Each user approves the provider’s consent screen once, and their tool calls use their own token. OAuth availability depends on your plan; see pricing.

Can different tools on one server use different credentials?

No. Authentication is configured per server and shared by all its tools. If you need two different keys, create two servers and give each its own credential.

What are test credentials for?

In a passthrough mode the server stores no credential of its own, so the admin Test Tool button needs one to call your API. Test Credentials fill that gap. They are used only by Test Tool and the chat playground, never by connected MCP clients.

Pick the pattern that matches who holds the keys, save it once, and every tool on the server follows it. See how GetMCP protects credentials end to end on the security page.