Lion Cipher Lab

MCP server, Part 2: add authentication and rate limiting — put a bearer-token check and a 429 rate limit in front of your HTTP MCP server (tested with curl, no API key needed)

• AI Security
• Intermediate
• ~45 min
• Free · no account required

Why it matters

The moment your MCP server stops being a local subprocess and starts listening on a network port, it becomes an exposed attack surface: anyone who can reach that port can call your tool. Two controls turn an open door into a guarded one. Authentication (proving who is calling) stops the 'anyone can call this' problem and the confused-deputy trap where an attacker borrows your server's access. Rate limiting (capping how often a caller can call) stops resource exhaustion and runaway cost — the OWASP 'Unrestricted Resource Consumption' failure that quietly runs up a bill or knocks the service…

What you'll learn

• promoting an MCP server from stdio to HTTP (streamable-http) transport
• adding bearer-token / API-key authentication as a trust boundary
• implementing a per-client token-bucket rate limit
• returning HTTP 401 / 403 / 429 correctly
• testing an HTTP endpoint with curl (bad token, good token, over-limit)
• reasoning about exposed attack surface, confused-deputy, and resource exhaustion
• judging when a local stdio server is enough and network exposure is NOT worth it

Steps in this lab

1. What changed since Part 1 — transport, and why a network port needs a guard
2. The two words: bearer token (auth) and rate limit (abuse control)
3. Why this matters: exposed surface, confused deputy, and resource exhaustion
4. When NOT to build this — stdio local is often enough
5. Set up (or reuse) the environment and confirm the SDK
6. Write the HTTP server with auth + a token-bucket rate limit
7. Prove the auth boundary with curl: missing -> 401, wrong -> 403, right -> 200
8. Prove the rate limit with curl: hammer it past 5 and watch 429 appear
9. Do it better: real OAuth 2.1, a gateway, and audit logging

Open the full interactive lab →