DEV Community: Coreframe Labs

Securing the Model Context Protocol (MCP): Building a Production-Ready, OAuth 2.1 Authenticated Server over HTTP

Coreframe Labs — Thu, 23 Jul 2026 12:27:34 +0000

Securing the Model Context Protocol (MCP): Building a Production-Ready, OAuth 2.1 Authenticated Server over HTTP

As engineering organizations connect Large Language Models (LLMs) to sensitive business databases and internal developer systems, secure communication boundaries are no longer optional.

While running Model Context Protocol (MCP) servers locally using standard input/output (stdio) depends on local process boundaries, deploying remote MCP services over HTTP transport exposes deep security risks. Relying on static, long-lived API keys creates a single point of failure and does not support multi-user data scoping.

To address this challenge, we built and open-sourced Coreframe Labs' Secure MCP Template, implementing a production-ready, spec-compliant OAuth 2.1 authorization layer on top of a Node.js/TypeScript server over Server-Sent Events (SSE).

The Core Problem: Why API Keys Fail in AI Agent Environments

In typical application architectures, an API key is granted to an external system, which then has full access to the target API. However, AI agents sit at a unique intersection: they serve multiple clients (such as Claude Desktop or Cursor), act on behalf of diverse enterprise users, and execute operations dynamically.

Passing static API keys through locally installed desktop agents creates significant risk:

No User-Level Auditing: The server cannot distinguish between different users executing commands through a shared client.
Over-Permissioned Access: If a token is compromised, the attacker gains full access to all exposed analytical tools.
No Expiration Rules: Static keys lack automatic revocation or dynamic rotation mechanisms.

Standardizing authorization via OAuth 2.1 solves these issues natively. It enforces Proof Key for Code Exchange (PKCE) for all clients, eliminates insecure implicit flows, and requires exact matching on redirect URIs.

Architectural Breakdown: The Secure Remote Handshake

Our open-source implementation follows the standard OAuth 2.1 authorization lifecycle for remote, HTTP-based MCP servers:

[ MCP Client / Host ] ───────── (1) GET /api/tools (No Token) ────────► [ Remote MCP Server ]
                      ◄──────── (2) 401 Unauthorized (PRM Pointer) ─────

[ MCP Client / Host ] ─── (3) Fetch Protected Resource Metadata ───────► [ OAuth Provider ]
                      ◄──────────── (4) Auth Endpoint & Scopes ──────────

[ MCP Client / Host ] ────────── (5) Authorize with PKCE (S256) ───────► [ OAuth Provider ]
                      ◄──────────────── (6) Scoped Bearer Token ─────────

[ MCP Client / Host ] ────────── (7) GET /api/tools (With Token) ───────► [ Remote MCP Server ]

1. The Initial Handshake & Discovery

When an unauthorized client attempts to access our exposed tools or resources, the server rejects the request with an HTTP 401 Unauthorized status. It attaches a WWW-Authenticate header containing a secure pointer to our Protected Resource Metadata (PRM) document:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp", resource_metadata="https://mcp-auth-demo-production-d421.up.railway.app/.well-known/oauth-protected-resource"

The client fetches this document to learn the authorization server's URL, supported token endpoints, and the specific permissions (scopes) required.

2. Client ID Metadata Documents (CIMD)

To prevent unauthorized clients from dynamically registering with our enterprise server, our implementation validates the client's identity using Client ID Metadata Documents (CIMD). This configuration replaces fragile, manually configured client secrets with dynamic, cryptographically verifiable documents hosted securely on the client's domain.

3. Constant-Time Cryptographic Verification

A common vulnerability in custom token validation logic is the use of non-constant-time string comparisons. Standard string operators (==) return false immediately upon detecting a character mismatch, exposing the system to timing-based side-channel attacks.

Our template mitigates this risk by enforcing constant-time comparisons across all token verification routes:

import { timingSafeEqual } from 'crypto';

export function verifyAccessToken(suppliedToken: string, expectedToken: string): boolean {
  const suppliedBuf = Buffer.from(suppliedToken);
  const expectedBuf = Buffer.from(expectedToken);

  if (suppliedBuf.length !== expectedBuf.length) {
    return false;
  }

  return timingSafeEqual(suppliedBuf, expectedBuf);
}

Try It Yourself: Deployment & Live Demo

We have deployed the live interactive demo on Railway to demonstrate this authorization handshake in real-time.

🎮 Live Interactive Demo: https://mcp-auth-demo-production-d421.up.railway.app/demo/
📦 GitHub Repository: https://github.com/CoreframeLabs/mcp-auth-template

To spin up the template locally, clone our repository and configure your environment variables:

git clone https://github.com/CoreframeLabs/mcp-auth-template.git
cd mcp-auth-template
npm install
npm run build
npm run test

Join the Discussion

Implementing security layers for remote AI agents is a rapidly evolving space.

How is your engineering team currently securing external integrations? Are you moving toward OAuth 2.1-compliant architectures, or relying on network-isolated VPC environments?

Share your architectural designs, feedback, or any security bottlenecks you've encountered in the comments below!

Why I chose ClickHouse over PostgreSQL for a billion-row analytics platform

Coreframe Labs — Wed, 01 Jul 2026 11:30:17 +0000

Last year I was handed a problem: an enterprise IoT monitoring dashboard that took 18–22 seconds to load. The client — a large industrial operator — had engineers staring at a spinner every time they opened it. The underlying data was billions of sensor readings, stored in PostgreSQL.

My job was to fix it. The solution ended up being ClickHouse. Here's exactly why, including the benchmarks and the tradeoffs I accepted to get there.

The Query That Broke Postgres

The dashboard had a "fleet overview" view that aggregated data across all sensor racks simultaneously. In simplified terms:

SELECT
    rack_id,
    quantile(0.95)(value) AS p95_reading,
    quantile(0.50)(value) AS median_reading,
    count()               AS sample_count
FROM sensor_readings
WHERE ts >= now() - INTERVAL 7 DAY
GROUP BY rack_id
ORDER BY p95_reading DESC

On PostgreSQL 16 with BRIN indexes on ts: 42,000ms. Query was being killed at 60 seconds in production. Users saw a broken dashboard and assumed the system was down.

On ClickHouse with MergeTree partitioned by month: 380ms.

That's not a configuration problem. That's a fundamentally different storage model.

Why Columnar Storage Wins for This Workload

PostgreSQL stores data row by row. To aggregate a column across millions of rows, it has to read every row — even the columns you don't need.

ClickHouse stores data column by column. An aggregation query reads only the columns it touches. For a table with 12 columns, that's roughly a 12x reduction in I/O before any other optimization kicks in.

On top of that, columnar storage compresses repetitively structured data extremely well. IoT sensor data is highly repetitive — the same sensor IDs, the same rack IDs, the same status codes, repeated billions of times. Our 1-billion-row dataset that occupied 847GB in PostgreSQL occupied 94GB in ClickHouse. A 9x compression ratio, on the same hardware.

Less data on disk means faster reads. Faster reads means faster queries. The math is straightforward.

The Benchmark Results

I ran three representative queries against the same 1-billion-row dataset on the same hardware (8-core CPU, 32GB RAM, NVMe SSD). Here's what came back:

Query 1: Count rows in a 24-hour window

Engine	Latency (p50)
PostgreSQL 16 (BRIN index)	1,240ms
TimescaleDB	310ms
ClickHouse	18ms

Query 2: 1-hour candle aggregation over 90 days

Engine	Latency (p50)
PostgreSQL 16	8,200ms
TimescaleDB (continuous aggregate)	95ms
ClickHouse (AggregatingMergeTree view)	8ms

Query 3: Cross-rack percentile across 7 days (the killer query)

Engine	Latency (p50)
PostgreSQL 16	42,000ms
TimescaleDB	18,000ms
ClickHouse	380ms

The third query is the one that mattered most. TimescaleDB at 18 seconds is still too slow for an interactive dashboard. ClickHouse at 380ms feels instant.

What Made the Difference: Materialised Views at Insert Time

The 8ms result on Query 2 wasn't just columnar storage. It was ClickHouse's AggregatingMergeTree materialised views — which compute aggregations at insert time, not at query time.

CREATE MATERIALIZED VIEW candles_1h
ENGINE = AggregatingMergeTree()
ORDER BY (asset, ts_bucket)
AS
SELECT
    asset,
    toStartOfHour(ts)         AS ts_bucket,
    argMinState(value, ts)    AS open,
    maxState(value)           AS high,
    minState(value)           AS low,
    argMaxState(value, ts)    AS close
FROM sensor_readings
GROUP BY asset, ts_bucket;

Every time data is inserted, ClickHouse updates the materialised view in the background. By the time a dashboard query arrives, the 1-hour candles are pre-computed. The query scans 2,160 rows (90 days × 24 hours) instead of 200 million raw readings.

TimescaleDB has something similar — continuous aggregates. The difference: TimescaleDB continuous aggregates break when the query uses dynamic intervals (users choosing arbitrary time windows). ClickHouse materialised views handle this correctly.

The Tradeoffs I Accepted

ClickHouse is not PostgreSQL. There are real things it can't do:

No row-level updates. UPDATE sensor_readings SET value = X WHERE id = Y is an async mutation in ClickHouse — expensive and non-atomic. For IoT data that's append-only, this doesn't matter. For data that needs corrections, you need a strategy (we used a separate corrections log in Postgres).

Joins are slow. ClickHouse joins are hash-based and don't benefit from indexes the way PostgreSQL does. We kept all relational data — users, device registry, permissions — in PostgreSQL and only put time-series data in ClickHouse.

Local development is heavy. ClickHouse in Docker takes 2–3 minutes to start and consumes significant RAM. We eventually moved to a shared dev instance rather than having every engineer run it locally.

No transactions. If you need BEGIN / COMMIT / ROLLBACK, ClickHouse can't help you.

The decision was straightforward for our workload: append-only time-series, aggregation-heavy queries, no relational joins on the hot path. If any of those conditions were different, the answer might have been different too.

The Result

Dashboard load time went from 18–22 seconds to under 1 second. Not through clever caching alone (though we added multi-tier Redis caching on top), but because the underlying queries went from multi-second to sub-100ms.

The client's engineers went from avoiding the fleet overview to opening it as their first action every morning.

When ClickHouse is the Wrong Answer

Don't use ClickHouse if:

Your queries are primarily point lookups by primary key
You need multi-table relational joins on the hot path
Your dataset is under ~100M rows (Postgres handles it fine)
You need ACID transactions
Your team has no bandwidth to learn a new query engine

ClickHouse solves one problem extremely well: aggregating over large amounts of time-ordered data. If that's your problem, it's the right tool. If it isn't, PostgreSQL is probably fine and you're adding operational complexity for no gain.

If you want to see the full schema design, materialised view definitions, and benchmark methodology: I wrote it up in detail in my IoT Architecture Playbook — specifically the storage strategy doc and the ClickHouse vs TimescaleDB ADR.