The official MCP TypeScript SDK 2.1.0 ships DPoP sender-constrained access tokens and request-time OAuth scope challenges. If you run or expose MCP servers, the upgrade path is concrete: prefer DPoP-bound tokens and per-tool scope challenges over long-lived bearer keys in agent hosts and CI.

What WorkOS Published

On September 29, 2026, WorkOS covered DPoP and scope challenges in the official MCP TypeScript SDK. The packages named are @modelcontextprotocol/client, core, server, and node at version 2.1.0. They implement authorization hardening from the 2026-07-28 MCP spec (SEP-1932 / RFC 9449 on the DPoP side).

WorkOS's framing: for most of the year the authorization spec described stronger controls faster than SDKs implemented them. This release closes that gap a little.

Why Bearer Tokens Were The Weak Point

MCP servers are reachable by an agent over the network — a laptop, a third-party host, a CI runner. A plain OAuth bearer token is a bearer instrument. Anyone who copies it from logs, a leaked environment variable, or a compromised dependency can use it as the legitimate client would. The resource server cannot tell the difference.

DPoP binds the access token to a client key pair. Every request carries a signed proof that the caller holds the private key the token was issued to. A stolen bearer without that key is worthless.

What 2.1.0 Ships

  • Client: dpop() on OAuthClientProvider, with automatic proof signing and a one-shot nonce retry on use_dpop_nonce.
  • Core helpers: generateDpopKeyPair, accessTokenHash, isDpopNonceChallenge.
  • Server: scopeChallenge on tool, resource, and prompt registration, plus a requireScopes helper.
  • Node: scope-challenge support wired into createMcpHandler.

When scopeChallenge returns a challenge, the transport sends HTTP 403 with a WWW-Authenticate header before the handler runs or an SSE stream opens. WorkOS's point: a partially authorized call should not leak tool behavior.

What Operators Should Change

Two concrete decisions, from the WorkOS post: decide whether your authorization server needs DPoP now (the spec does not mandate it yet, but client support is no longer theoretical), and stop treating "has a valid token" as "is allowed to do this specific thing." Destructive tools — delete, pay, write to a shared resource — should live behind their own scope, challenged at call time.

What The Post Does Not Prove

  • This is WorkOS coverage of the official SDK release. Confirm types against the SDK itself before shipping; WorkOS notes the release is new and details may shift.
  • DPoP is not mandatory in the spec yet. Bearer tokens remain stealable if you keep issuing them.
  • SDK hardening is not a substitute for registry and management-plane auth.

Related: See our notes on ungoverned MCP registries and gateway admin auth, agent-credential architectures, and WorkOS Airlock.