How to Secure an MCP Server: Authentication, OAuth, and Best Practices

An MCP server is a bridge between an AI model and your systems. That is what makes it useful, and it is also why security matters. A poorly protected server can expose customer data, allow unintended actions, or become an entry point into internal infrastructure. The good news is that the protocol now defines a clear authorization model, and a handful of practices cover most of the risk.

Start with the right access model

Not every server needs the same protection. A server that returns public documentation can be open. A server used by one internal team can rely on API keys or bearer tokens stored in the client configuration. A server that acts on behalf of individual users, such as reading their tickets or calendar, needs user-level authorization so that each person only sees and changes what they are allowed to.

How MCP authorization works

For servers exposed over HTTP, the MCP specification builds on OAuth 2.1. The MCP server acts as an OAuth resource server and accepts access tokens issued by an authorization server, which can be your existing identity provider. The server publishes protected resource metadata (RFC 9728) so that clients can discover which authorization server to use. When a request arrives without a valid token, the server responds with 401 and points the client to that metadata.

Clients then run a standard OAuth flow with PKCE, ask the user for consent, and include the resulting token on every request. Clients also indicate which server the token is for using resource indicators (RFC 8707), and servers must reject tokens that were issued for a different audience. The most recent revisions of the specification have strengthened client registration and issuer validation, so it is worth following the current version rather than an older tutorial.

Best practices for production servers

Validate every token: check the signature, issuer, audience, and expiry on each request. Never accept a token just because it is present.

Do not pass tokens through: an MCP server should not forward the access token it received to downstream APIs. Use separate credentials for those calls so that a token issued for your MCP server cannot be replayed elsewhere.

Apply least privilege to tools: give each tool the narrowest permissions it needs. A tool that reads invoices should not be able to delete them, and destructive actions should require explicit confirmation from the user.

Keep secrets out of code: store API keys and database credentials in an encrypted secret store and reference them at runtime. Make sure they never appear in logs or error messages.

Validate inputs: treat every argument from the model as untrusted. Check types, lengths, and allowed values, and use parameterized queries for anything that touches a database.

Defend against prompt injection: content returned by tools, such as emails or web pages, can contain instructions aimed at the model. Keep tool outputs clearly separated from instructions, and avoid tools that can both read untrusted content and take high-impact actions without review.

Rate limit and monitor: set limits per client and per tool, log every call with its inputs and outcome, and alert on unusual patterns such as sudden spikes or repeated failures.

Enterprise requirements

Larger organizations usually need single sign-on with their identity provider, audit logs, and control over where the server runs. Plan for these early, because retrofitting identity and logging into a server that is already in use is far harder than designing them in.

How MCPCore handles this

We built MCPCore so that teams do not have to implement this layer themselves. Each server can be set to Public, API Key, OAuth 2.0, or Bearer Token authentication. Secrets are stored with AES-256 encryption, rate limiting is built in, and every failed call is logged with its inputs and stack trace. Enterprise customers can connect Auth0, Okta, or Keycloak for single sign-on, or run MCPCore inside their own environment.