AWS appstream2: Add supported MCP protocol versions and clarify OAuth/IAM authorization
Summary
Adds a new 'Supported MCP protocol versions' section listing stateful (2025-03-26, 2025-06-18, 2025-11-25) and stateless (2026-07-28) MCP versions and how sessions end per version. Also rewords the OAuth 2.1 / AWS Sign-In authorization and session-identification guidance (interactive vs. non-interactive authorization, header-based session creation).
Security assessment
The changed content documents the MCP server's authorization model: SigV4/IAM-signed requests or OAuth 2.1 bearer tokens issued by AWS Sign-In, with short-lived scoped tokens and every request still evaluated against IAM policies. This is security best-practice/feature documentation (least privilege, scoped short-lived credentials) rather than a fix for a specific vulnerability; the protocol-version addition is functional.
Evidence
+As an alternative to signing requests with IAM credentials, the MCP server supports OAuth 2.1 authorization through AWS Sign-In, the same way as the AWS MCP Server. AWS Sign-In acts as the authorization server. It issues short-lived, scoped access tokens, and the MCP server accepts these tokens as bearer tokens. OAuth uses your existing IAM identities, permissions, and organizational controls. When you authorize an agent, it can access the MCP server on your behalf without gaining extra permissions. AWS still checks every request against your IAM policies.
Diff
diff --git a/appstream2/latest/developerguide/agent-access-mcp-server-endpoint.md b/appstream2/latest/developerguide/agent-access-mcp-server-endpoint.md index dcf6023..df7e5e9 100644 --- a//appstream2/latest/developerguide/agent-access-mcp-server-endpoint.md +++ b//appstream2/latest/developerguide/agent-access-mcp-server-endpoint.md @@ -7 +7 @@ -Request authorizationSession identificationCompatible frameworks +Supported MCP protocol versionsRequest authorizationSession identificationCompatible frameworks @@ -11 +11 @@ Request authorizationSession identificationCompatible frameworks -This topic explains how to connect an agent to the WorkSpaces Applications Model Context Protocol (MCP) server, from the endpoint it calls to how it authorizes its requests and identifies a streaming session. +This topic explains how to connect an agent to the Amazon WorkSpaces Applications Model Context Protocol (MCP) server. Connecting involves negotiating an MCP protocol version with the server and authorizing each request. This topic covers the endpoint the agent calls, how it authorizes its requests, and how it identifies a streaming session. @@ -25,0 +26,13 @@ Before an agent can connect, the fleet associated with your stack must be runnin +## Supported MCP protocol versions + +The MCP server supports the following versions of the Model Context Protocol. Your MCP client negotiates the version with the server when it connects. + +Version | Type +---|--- +2025-03-26 | Stateful +2025-06-18 | Stateful +2025-11-25 | Stateful +2026-07-28 | Stateless + +Version 2026-07-28 is the stateless MCP protocol. With the stateless protocol, the agent ends the session with the `close_session` tool. For more information about the tool, see [Available tools](./agent-access-mcp-server-tools.html). With the earlier MCP protocol versions, you end the session by closing the MCP client in your agent code, which sends an HTTP `DELETE` request. For more information, see [Session cleanup](./agent-access-mcp-server-session-cleanup.html). + @@ -55 +68 @@ For other languages, write your own SigV4 signing logic for outgoing MCP request -As an alternative to signing requests with IAM credentials, the MCP server supports OAuth 2.1 authorization through AWS Sign-In, the same way as the AWS MCP Server. AWS Sign-In acts as the authorization server. It issues short-lived, scoped access tokens, and the MCP server accepts these tokens as bearer tokens. OAuth uses your existing IAM identities, permissions, and organizational controls. When you authorize an agent, it can access the MCP server on your behalf without gaining extra permissions, and AWS still checks every request against your IAM policies. +As an alternative to signing requests with IAM credentials, the MCP server supports OAuth 2.1 authorization through AWS Sign-In, the same way as the AWS MCP Server. AWS Sign-In acts as the authorization server. It issues short-lived, scoped access tokens, and the MCP server accepts these tokens as bearer tokens. OAuth uses your existing IAM identities, permissions, and organizational controls. When you authorize an agent, it can access the MCP server on your behalf without gaining extra permissions. AWS still checks every request against your IAM policies. @@ -59 +72 @@ OAuth-compatible MCP clients, such as Kiro, Claude Code, Cursor, Codex, and Gemi - * **Interactive authorization**. For agents that can open a browser. The client registers through dynamic client registration, redirects you to an AWS Sign-In page to authenticate and approve access, and AWS Sign-In then issues and refreshes the access tokens. + * **Interactive authorization** – This model is for agents that can open a browser. The client registers through dynamic client registration and redirects you to an AWS Sign-In page to authenticate and approve access. AWS Sign-In then issues and refreshes the access tokens. @@ -61 +74 @@ OAuth-compatible MCP clients, such as Kiro, Claude Code, Cursor, Codex, and Gemi - * **Non-interactive authorization**. For agents that already have AWS credentials and run without a browser (sometimes called headless authorization). The agent uses the OAuth client credentials grant to exchange SigV4-signed credentials for a short-lived access token. + * **Non-interactive authorization** – This model is for agents that already have AWS credentials and run without a browser (headless authorization). The agent exchanges its SigV4-signed credentials for a short-lived access token by using the OAuth client credentials grant. @@ -78 +91 @@ At any given time, only one agent can connect to a unique session. Named users, -For non-domain-joined fleets, you can connect in one of two ways. Provide the stack and user ID as headers, and the MCP server creates the streaming session for you. This suits statically configured MCP clients, because they can hold a fixed pair of headers but cannot generate a streaming URL or replace one when it expires. Alternatively, generate a streaming URL yourself and pass it as a header. Use this approach when you need control over session creation, such as setting the validity period. +For non-domain-joined fleets, you can connect in one of two ways. Provide the stack and user ID as headers, and the MCP server creates the streaming session for you. This suits statically configured MCP clients, because they can hold a fixed pair of headers. However, they cannot generate a streaming URL or replace one when it expires. Alternatively, generate a streaming URL yourself and pass it as a header. Use this approach when you need control over session creation, such as setting the validity period.