Protect an MCP server with an Authorization Server

/ Blog

Light<br>Dark<br>System

Log In

Get a demo

Open main menu

Education<br>Protect an MCP server with an Authorization Server<br>MCP servers can expose sensitive data and business logic to AI agents. Learn how to lock them down using OAuth.

Authors

Dan Moore

Published: June 15, 2026

The Model Context Protocol (MCP) is rapidly becoming the standardized API for large language models (LLMs) to interact with business logic. Like the early days of REST, builders are moving fast, often prioritizing functionality over security.

We’re already seeing the security mistakes we made a decade ago showing up with this new technology.

You can see some of these in the MCP security advisory list, which lists path traversal, path validation, and injection issues. From broken tenant isolation, to networking misconfiguration, to tool poisoning, you want to avoid the negative impact. Because agents act autonomously, a misconfigured MCP server allows more damage than a REST endpoint.

The simplest mitigation? Require authentication and authorization using an Authorization Server (AS). Lock down your MCP server if it provides access to anything confidential, or if the data and functionality it offers varies depending on the user making the request. You don't need authentication for public documentation or shared resources (like our FusionAuth docs MCP server), but anything beyond that needs a proper security layer.

Actually, they need two. One in front of the MCP server, which is what this post will discuss. And one behind it, which is touched on but is not covered by the standard.

The MCP specification does not enforce security at the protocol level, so "left to the implementer" often becomes "skipped until a breach forces re-evaluation". Don't let that be you.

Luckily, MCP does specify a way for you to secure your remote server with OAuth. I guess we learned something from the mistakes of the REST era.

This approach delegates authentication to an AS, which verifies who the user is and what their permissions are before the request hits your server. This is done through the OAuth Authorization Code grant, using well-known concepts like scopes and consents. While there's an MCP extension which allows for client credentials access, this post focuses on the more typical "on-behalf-of" flow, where the user explicitly grants the MCP client access to the MCP server on their behalf.

Here is the flow that gets an MCP client authenticated and authorized to use your protected remote MCP server:

MCP server discovery

MCP client registration

user authentication

grant of consent

access token issuance

access token validation

use the MCP

Let's take a look at each of these.

MCP Server Discovery#

First, the MCP client (like Claude Desktop or an AI agent) needs to be configured with the location of your MCP server. How this is done depends on your MCP client, but can range from editing a JSON file to adding a URL to a form.

When the client first hits your MCP server, the server says, “I don’t know you. Go here to get me credentials”. RFC 9728 outlines the technical details of this redirection.

This response sends the client to an AS trusted by the MCP server.

Client Registration#

When the MCP client gets to the AS, the AS needs to know some things about it.

There are a few ways for this to happen. In the order of evaluation per the spec:

Pre-register the MCP client with the AS . This means that some other process created a link between the MCP client and AS. This is referred to as "out of band" but really means "we don't know and we don't care how it happened, as long as it happened". This is similar to showing up to a formal gala party and flashing your invitation. You've been invited and are known before you talk to the person at the door.

Register the MCP client when it first interacts with the AS . There are two technical paths, Client ID Metadata Documents (CIMD) and Dynamic Client Registration (DCR). The former is newer but seems to be the future, with the latter being explicitly retained for backwards compatibility. This is similar to a bouncer checking a driver's license at a bar. As long as you meet certain criteria, you're in.

Prompt the user for credentials. I haven't seen this in the wild, but it pushes the coordination work onto the human. This is like showing up to a party without an invitation and having the host come to the door to personally vouch for you.

Which client registration process you choose affects the security/friction tradeoff.

Using the pre-registration process means that you'll know which MCP clients can interact with your server, but you'll have to configure each client in advance.

Using CIMD or DCR reduces friction by establishing the client just-in-time: an MCP client can register itself even if it has never before used the AS. But don't worry, these methods don't expose your endpoint to any arbitrary client:

the user still must have a...