Build an Auth0-protected MCP server

## Hands-on OA: Build an MCP server secured by Auth0 JWTs You are asked to build a local HTTP service that implements a minimal **MCP (Model Context Protocol)** server with one tool: **`whoami`**. The server must be protected by **Auth0-issued JWT access tokens**. ### Requirements #### 1) JWT authentication middleware Implement middleware that validates incoming requests using a `Bearer` token in the `Authorization` header. The JWT must be validated as follows: - **Signature algorithm:** RS256 - **Signature verification:** Use Auth0’s public keys (JWKS) - **Claims validation:** - `iss` (issuer) must match the configured Auth0 issuer - `aud` (audience) must match the configured API audience - `iat` and `exp` must be validated (token not expired; issued-at is reasonable) - **Client identity requirement:** token must include **either** `azp` **or** `client_id` #### 2) Tool authorization (scope check) The MCP tool `whoami` must only be callable if the token contains the scope: - Required scope: `tool:whoami` (Assume scopes are delivered in the token as a space-delimited `scope` claim; you may also support `permissions` if present.) #### 3) Error handling Return standard HTTP errors: - **401 Unauthorized** for missing/invalid tokens (bad signature, wrong issuer/audience, expired, etc.) - **403 Forbidden** for valid tokens that lack required permissions/scope #### 4) `whoami` tool behavior When authorized, the `whoami` tool should return basic identity information derived from the validated token (e.g., subject/user id, client id, issuer, audience, scopes). ### Deliverable A locally runnable server that successfully starts and can be called with a real Auth0 access token. The `whoami` tool must be protected by the JWT middleware and the `tool:whoami` scope.