MCP Server Hosting With Authentication: OAuth vs Bearer Keys

A hosted MCP server must authenticate every request. Use OAuth 2.1 with protected-resource metadata when assistants sign users in, and scoped bearer keys, one per agent, for developer tools and internal automation. Keep upstream credentials server-side, allow only needed tools per key, and make revocation instant.

Why authentication is the first decision

A remote MCP server is a public network service that can take actions. Unlike a local stdio server, whose trust boundary is your operating system user, a remote one needs real credentials or anyone with the URL can call its tools. BusinessMCP’s remote versus local guide puts it plainly in its comparison: local needs no auth, remote requires OAuth or scoped tokens.

The two main mechanisms

	OAuth 2.1 flow	Bearer key
Typical user	Person connecting via an assistant’s connector UI	Developer, script or internal agent
Setup for the user	Sign in, approve consent screen	Paste a key into a config
Rotation	Token refresh, automatic	Manual, by policy
Revocation	Revoke grant or token	Delete the key
Best for	Claude.ai or ChatGPT connectors, many users	Cursor, VS Code, custom agents
Build effort	Higher: metadata, consent, token endpoints	Lower

The MCP authorization specification treats an HTTP MCP server as an OAuth resource server. A client discovers how to authenticate through protected-resource metadata (RFC 9728), which points to an authorization server, then runs the usual flow with PKCE. The result is the “paste a URL, sign in, tools appear” experience.

Bearer keys are simpler and more transparent for technical users. BusinessMCP supports both: a Bearer key for the /api/mcp endpoint and an OAuth 2.1 server with PKCE, which it says is included so Claude.ai’s custom-connector UI can connect. Its consent screen offers scoped presets. Keys in its guides carry an mcph_ prefix and are scoped to a workspace.

Key takeaway: authentication tells you who is calling; authorisation decides what they may do. A hosted server needs both, and the second matters more.

Authorisation: scope what each key can do

Authentication alone gives a caller everything the server can do. The controls that matter next:

1. One key per consumer. If an agent misbehaves or a key leaks, you cut one key.
2. Tool allowlists per key. An agent that summarises analytics should not have a “send email” tool.
3. Write, delete and send tools off by default. Switch them on deliberately.
4. Data-class policies. BusinessMCP builds policies from data classes such as revenue, contact PII, enrichment, behaviour and messaging; restricted keys advertise fewer tools and have output redacted. Preset scoping begins at its Growth plan, with custom policies at Business, according to its plan table.
5. Approval gates. The agent proposes, a human confirms, for anything irreversible.

Read the access-control documentation for how one platform models this, and compare with whatever you are building.

Storing the credentials your server uses

Servers usually call upstream APIs with their own credentials. Keep these away from agents:

• Encrypt at rest.
• Resolve at call time on the server.
• Never include in tool output or error text.
• Scope upstream tokens narrowly, read-only where possible.

BusinessMCP says source credentials sit in an encrypted vault and agents never see raw secrets; check that any host you use can say the same.

Implementing it yourself

A practical order of work:

1. Start with bearer tokens, hashed at rest, with a label, scope list and last-used time per key.
2. Add per-key tool allowlists in the request handler.
3. Add logging that records key id, tool, arguments and result.
4. Add rate limits per key.
5. Add OAuth when non-developers need to connect: protected-resource metadata, an authorization server (your own or a provider), consent screen and refresh.
6. Add revocation tests to your release checklist.

Mistakes to avoid

Mistake	Better practice
One shared key for all agents	One key per agent
Keys in client config committed to git	Secrets manager, rotate on exposure
Auth on tools/call only	Auth on every request, including tools/list
Static key for consumer assistants	OAuth with consent
No expiry or rotation	Rotate on a schedule and on suspicion
Logging secrets in arguments	Redact before logging

A 401 from a server is not an error in monitoring terms: it means the server is alive and wants credentials. The failure is a 401 on valid credentials, a distinction covered in MCP server monitoring.

Where this fits in the bigger picture

Authentication is one row in the production requirements checklist and one layer in MCP server security. Get it right early; retrofitting auth onto a server that agents already use is disruptive.

Designing the consent and scope model

If you build OAuth yourself, the consent screen is where authentication meets authorisation. A consent screen that just says “allow access” teaches users to click through. A good one names what the connection can do in plain language, such as “read your analytics” or “send email on your behalf”, and offers narrower presets. BusinessMCP’s page says its consent screen offers scoped presets, which is the right pattern even if you copy nothing else.

Think through three scoping questions before you write code:

1. What are the natural permission groups? Group tools by data class or action type, not by function name. Revenue data, contact details, messaging and behaviour data are different risks.
2. What is the default? Make read-only the default and require an explicit choice for write.
3. What can a user revoke later? Provide a place to see active grants and revoke them. Ask whether revoking at the assistant also revokes at your server.

Testing your authentication

Test, do not assume:

Test	Expected result
Call tools/list without credentials	401, with a hint pointing to metadata
Call with a revoked key	Rejected immediately
Call a write tool with a read-only key	Tool not listed or call refused
Replay an expired OAuth token	Rejected, client refreshes
Read another tenant’s data with your key	Denied
Fetch the protected-resource metadata	Valid JSON naming your authorization server

Run this table as part of your release process. Authentication regressions are quiet: everything keeps working for legitimate users while the door stays open for everyone else.

Finally, remember that your monitoring needs a credential too. Give it a read-only key so health checks can reach tools/list, and see MCP server monitoring for the rest.