Multi-Tenant MCP Server Authentication with Redis Session Management

braingrid · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Production MCP authentication

BrainGrid needed to turn a local single-user MCP server into a secure multi-tenant service without forcing repeated authentication on stateless serverless platforms.

Constraints:

Cloud Run and Vercel do not preserve in-memory sessions across instances.
Scale-to-zero and load balancing can send requests to different instances.
Full JWT validation adds 50-100ms per request.
MCP tools need secure multi-user authentication and authorization.

Architecture

BrainGrid implemented Redis-backed encrypted session storage with AES-256-GCM, WorkOS OAuth, in-memory plus Redis caches, and a fast-path/slow-path authentication middleware that only performs full JWT validation when caches miss.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  mcp-server["MCP Server"]
  authentication-middleware["Authentication Middleware"]
  in-memory-cache["In-Memory Cache"]
  redis-session-store["Redis Session Store"]
  aes-256-gcm-encryption["AES-256-GCM Encryption"]
  workos-oauth["WorkOS OAuth"]
  mcp-server --> authentication-middleware
  authentication-middleware --> in-memory-cache
  authentication-middleware --> redis-session-store
  authentication-middleware --> workos-oauth
  in-memory-cache --> authentication-middleware
  redis-session-store --> authentication-middleware
  redis-session-store --> aes-256-gcm-encryption
  aes-256-gcm-encryption --> redis-session-store
  workos-oauth --> authentication-middleware

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`MCP Server`	Exposes developer workflow tools to AI assistants.	`Authentication Middleware`
`Authentication Middleware`	Executes fast-path cache checks or slow-path JWT validation.	`In-Memory Cache`, `Redis Session Store`, `WorkOS OAuth`
`In-Memory Cache`	Provides per-instance fast session lookup.	`Authentication Middleware`
`Redis Session Store`	Persists encrypted sessions across serverless instances.	`Authentication Middleware`, `AES-256-GCM Encryption`
`AES-256-GCM Encryption`	Protects session payloads at rest and detects tampering.	`Redis Session Store`
`WorkOS OAuth`	Provides OAuth and JWT validation inputs.	`Authentication Middleware`

Data flow

An MCP request first checks in-memory cache, then Redis for encrypted session state. If neither contains a valid session, the slow path performs JWT validation through WorkOS/JWKS, stores the encrypted session in Redis with TTL, and subsequent requests take the fast path.

“incoming requests first check an in-memory cache on the instance, then check Redis for cached sessions, and only fall back to full JWT validation if neither cache contains valid session data.”summary, stated

“OAuth integration via WorkOS, and a fast-path/slow-path authentication pattern that caches validated JWT sessions.”summary, stated

Why this architecture

A shared Redis session store solves the mismatch between stateful MCP sessions and stateless serverless deployment, while encryption and cache layering preserve security and latency.

“serverless platforms like Google Cloud Run and Vercel have unpredictable instance lifecycles characterized by cold starts, scale-to-zero behavior, horizontal scaling across multiple instances, and no sticky session support.”summary, stated

“Redis-based session store with military-grade encryption to maintain authentication state across serverless instances.”summary, stated

Models used: MCP-compatible AI assistants · Claude

Scale

Full JWT validation added about 50-100ms per request.
“This 50-100ms overhead on every request significantly degrades user experience and increases cloud costs”summary, stated
Redis sessions default to a 7-day TTL.
“stored in Redis with an automatic TTL (time-to-live) of 7 days by default.”summary, stated
The encryption key must be exactly 32 bytes or 64 hex characters.
“The encryption key is stored as a Kubernetes secret or environment variable and must be exactly 32 bytes (64 hex characters).”summary, stated

Alternatives considered (roads not taken)

In-memory sessions on serverless instances

Rejected because: Instances scale to zero or requests land on different instances, losing sessions.

“any in-memory session storage is ephemeral and isolated to individual instances”summary, stated

Local install for every user

Rejected because: It creates support burden around repos, dependencies, API keys, rotation, updates, and conflicts.

“each user must clone repositories, manage dependencies, configure API keys, handle key rotation, pull updates, and resolve environment conflicts.”summary, stated

Patterns

`tool-use-orchestration` (architecture)

The MCP server exposes Jira, database, and workflow actions to AI assistants.

“BrainGrid's MCP server enables AI assistants to create Jira tickets, query databases, and perform other developer workflow actions.”summary, stated

`safety-policy-enforcement` (governance)

OAuth, JWT validation, encrypted sessions, and tamper detection enforce secure multi-tenant access.

“proper authentication and authorization.”summary, stated

Tradeoffs

Use Redis-backed sessions

Chose Shared encrypted session state over Stateless full JWT validation on every request.

Rationale: Redis eliminates repeated 50-100ms validation and re-authentication fatigue.

“reduced authentication overhead from 50-100ms per request to near-instantaneous for cached sessions”summary, stated

Fail fast when Redis is unavailable

Chose enableOfflineQueue set to false over Queueing commands while Redis is down.

Rationale: Authentication infrastructure should surface failures instead of silently accumulating stale work.

“enableOfflineQueue set to false to fail fast rather than queueing commands when Redis is unavailable.”summary, stated

Gotchas (what bit them)

Serverless scale-to-zero breaks session continuity.

Root cause: In-memory authentication state disappears or stays isolated to one instance.

Resolution: Store encrypted sessions in Redis with fast-path cache checks.

“being forced to re-authenticate just minutes later when Cloud Run scales the instance to zero or when load balancing directs their request to a different instance.”summary, stated

Persistent sessions must not expose sensitive data in Redis.

Root cause: Redis becomes shared authentication state for many tenants.

Resolution: Encrypt JSON session payloads with AES-256-GCM and verify auth tags on read.

“verifying the authentication tag to detect any tampering, and decrypting to recover the original session object.”summary, stated

Evaluation

BrainGrid evaluates through authentication overhead, cached-session latency, re-authentication frequency, and production multi-tenant deployability.

Metrics: JWT validation overhead · cached-session latency · session TTL · re-authentication frequency

“reduced authentication overhead from 50-100ms per request to near-instantaneous for cached sessions, eliminated re-authentication fatigue”summary, stated

Outcomes

BrainGrid moved MCP authentication from local single-user usage toward multi-tenant production deployment.
Cached sessions eliminated repeated authentication prompts.
Authentication overhead dropped from 50-100ms to near-instantaneous for cached sessions.

The architecture targets multi-tenant customer deployment on serverless platforms.

“enabled the MCP server to scale from single-user to multi-tenant deployment while maintaining security and performance.”summary, stated