Implementing Identity-Aware MCP Servers

Three Questions the Medium Article Answers

🔑 1. Which OAuth 2.0 roles and grant flows actually matter for an MCP stack?

Four canonical roles

Role	In an MCP deployment
Resource owner	End user launching an MCP-powered agent (e.g., Strava analytics bot)
Client	The MCP host/agent code that calls tools
Resource server	The MCP server exposing tool endpoints (/strava:get_activities, …)
Authorization server	IdP such as AWS Cognito that mints JWTs

Two grant types worth knowing

Grant	When to use	Flow-at-a-glance
Authorization Code	Agent acts on behalf of a user (Strava requires it)	User consents ➜ code ➜ access + refresh tokens
Client Credentials	Agent needs its own service account (no user UI)	Client ID + secret ➜ access + refresh tokens

Tip: Separate authorization and resource servers for tighter security and independent scaling—even though OAuth2 doesn’t force you to.

---

🔒 2. How do tokens flow through an identity-aware MCP call path?

User → MCP Host (Client) ⟶ ① access_token
                         ⟶ MCP Server ⟶ ② access_token
                                         ⟶ Backend API

1. Client → Server security
   Preferred: client-credentials grant. The client trades its ID + secret for an access_token whose scopes encode allowed tools (e.g., mcp.heeki.cloud/strava:get_activities).
   Server logic: Decode JWT, verify required scopes before running the tool.
2. Server → Backend API security
   Often required: authorization-code grant (e.g., Strava). The host passes the user’s access_token in the request payload; the MCP server forwards it downstream.

JWT cheat-sheet

sub   → user or client ID
aud   → intended audience (client)
scope → space-delimited tool permissions
exp   → expiry (short-lived!)

---

🛠️ 3. What implementation hurdles show up in real life?

Hurdle	What Park tried	Engineering takeaway
Custom scopes in Cognito	Six tool scopes (mcp.heeki.cloud/...) inside a resource server	Works, but Cognito lacks Dynamic Client Registration (DCR), so MCP Inspector’s auto-test fails.
MCP Python SDK limits	v1.7.0 only supports auth-code flow	Client-credentials support is pending in an open PR—patch or fork until merged.
Testing with MCP Inspector	Requires DCR; Strava & Cognito don’t provide it	A PR adds manual client-ID entry; until merged, testing is tricky without DCR.

---

The bottom line

Master these pieces and you’ll deploy MCP servers that are both context-rich and breach-resistant:

1. Understand the four OAuth roles and map them to MCP.
2. Choose the right grant—auth-code for user flows, client-credentials for service calls.
3. Treat JWT scopes as your fine-grained permission model.
4. Validate every token (signature, exp, aud).
5. Expect integration friction while SDKs and IdPs catch up to MCP’s rapid evolution.

Get those fundamentals right, and even beginners on your team can wire secure, identity-aware AI agents with confidence.

---