From a6350915df685d1cc62b54ff7c0efec391164639 Mon Sep 17 00:00:00 2001 From: Nate Barbettini Date: Thu, 13 Nov 2025 07:19:26 -0800 Subject: [PATCH] Elicitation: clarify language on auth URL in external OAuth guidance --- docs/specification/draft/client/elicitation.mdx | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/specification/draft/client/elicitation.mdx b/docs/specification/draft/client/elicitation.mdx index a82d9fd08..93627c6be 100644 --- a/docs/specification/draft/client/elicitation.mdx +++ b/docs/specification/draft/client/elicitation.mdx @@ -630,11 +630,12 @@ Credentials obtained via URL mode elicitation are distinct from the MCP server c When implementing external authorization via URL mode elicitation: 1. The MCP server generates an authorization URL, acting as an OAuth client to the third-party service -2. The server creates a URL mode elicitation request with this URL -3. The user completes the OAuth flow directly with the third-party authorization server -4. The third-party authorization server redirects back to the MCP server -5. The MCP server securely stores the third-party tokens, bound to the user's identity -6. Future MCP requests can leverage these stored tokens for API access to the third-party resource server +2. The MCP server stores internal state that associates (binds) the elicitation request with the user's identity. +3. The MCP server sends a URL mode elicitation request to the client with a URL that can start the authorization flow. +4. The user completes the OAuth flow directly with the third-party authorization server +5. The third-party authorization server redirects back to the MCP server +6. The MCP server securely stores the third-party tokens, bound to the user's identity +7. Future MCP requests can leverage these stored tokens for API access to the third-party resource server The following is a non-normative example of how this pattern could be implemented: