MCP Auth in Production: Issuer-Bound Enrollment and Tokens
Lesson 16 built the OAuth 2.1 state machine. This lesson hardens its production boundaries for MCP 2026-07-28: Client ID Metadata Documents first, deprecated dynamic registration only for compatibility, authorization-response issuer validation, issuer-keyed client credentials, JWKS refresh, and audience-pinned tokens on every stateless request. Discover an authorization server through RFC 8414 metadata and verify the contract. Enroll through a Client ID Metadata Document and isolate deprecated DCR as a fallback. Validate RFC 9207 iss, key registrations by authorization-server issuer, and key resource-bound tokens by issuer plus resource. Cache and refresh JWKS keys on a schedule so signature verification survives key roll-over. Pin tokens to a single MCP resource using RFC 8707 resource indicators and refuse confused-deputy reuse. Choose JWT validation or token introspection, define revocation freshness, and fail safely when identity dependencies are unavailable. Separate the authorization server, resource server, and client so each enforces only its own checks. Audit an authorization server against a deployment checklist and refuse unsafe enrollment or token reuse. The Lesson 16 simulator runs OAuth 2.1 in memory. Production has three operational gaps that a memory-only simulator does not see. The first gap is enrollment and credential isolation. A real org may run hundreds of MCP servers and thousands of MCP clients. The 2026-07-28 revision prefers a Client ID Metadata Document: the client uses an HTTPS…
MCP Auth in Production: Issuer-Bound Enrollment and Tokens: Lesson 16 built the OAuth 2.1 state machine. This lesson hardens its production boundaries for MCP…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.