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
- 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. - 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:
- Understand the four OAuth roles and map them to MCP.
- Choose the right grant—auth-code for user flows, client-credentials for service calls.
- Treat JWT scopes as your fine-grained permission model.
- Validate every token (signature,
exp,aud). - 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.
