Document vMCP embedded auth server and upstream token injection

Closes #642

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: jhrozek

docs/toolhive/concepts/backend-auth.mdx

@@ -211,20 +211,10 @@ deployments using the ToolHive Operator.
 - **Direct upstream redirect:** The embedded authorization server redirects
   clients directly to the upstream provider for authentication (for example,
   GitHub or Atlassian).
-- **Single upstream provider:** Currently supports one upstream identity
-  provider per configuration.
-
-:::info[Chained authentication not yet supported]
-
-The embedded authorization server redirects clients directly to the upstream
-provider. This means the upstream provider must be the service whose API the MCP
-server calls. Chained authentication—where a client authenticates with a
-corporate IdP like Okta, which then federates to an external provider like
-GitHub—is not yet supported. If your deployment requires this pattern, consider
-using [token exchange](#same-idp-with-token-exchange) with a federated identity
-provider instead.
-
-:::
+- **Single upstream provider per MCPServer:** Individual MCPServer resources
+  support one upstream identity provider per configuration. For multiple
+  upstream providers with sequential authorization chaining, use a
+  [VirtualMCPServer with the embedded auth server](../guides-vmcp/authentication.mdx#embedded-authorization-server).
 
 #### Token storage and forwarding
 
@@ -286,6 +276,8 @@ For the client-facing OAuth flow, see
 [Embedded authorization server](./auth-framework.mdx#embedded-authorization-server).
 For Kubernetes setup instructions, see
 [Set up embedded authorization server authentication](../guides-k8s/auth-k8s.mdx#set-up-embedded-authorization-server-authentication).
+For multi-upstream provider support with vMCP, see
+[vMCP embedded authorization server](../guides-vmcp/authentication.mdx#embedded-authorization-server).
 
 ## Token exchange in depth
 

docs/toolhive/concepts/vmcp.mdx

@@ -22,7 +22,7 @@ pre-configured tools with sensible defaults.
 
 ## Core value propositions
 
-vMCP delivers four key benefits:
+vMCP delivers five key benefits:
 
 1. **Reduce complexity**: Many connections become one, dramatically simplifying
    configuration
@@ -136,6 +136,16 @@ your identity provider and all backend access is revoked instantly.
 This approach provides single sign-on for users, centralized access control, and
 a complete audit trail.
 
+vMCP can also run an embedded authorization server that handles the full OAuth
+flow with multiple upstream identity providers (such as GitHub, Google, or
+Okta). This enables per-user backend authentication: when a user logs in, the
+auth server acquires tokens from each upstream provider and injects them into
+requests to the appropriate backends. MCP clients register automatically through
+Dynamic Client Registration (DCR), so no manual client configuration is needed.
+See
+[Authentication](../guides-vmcp/authentication.mdx#embedded-authorization-server)
+for setup details.
+
 ## When to use vMCP
 
 ### Good fit

docs/toolhive/guides-k8s/auth-k8s.mdx

@@ -766,6 +766,8 @@ kubectl logs -n toolhive-system -l app.kubernetes.io/name=weather-server-k8s
   [Authentication and authorization framework](../concepts/auth-framework.mdx)
 - For conceptual background on the embedded authorization server, see
   [Embedded authorization server](../concepts/auth-framework.mdx#embedded-authorization-server)
+- For multi-upstream provider support with vMCP, see
+  [vMCP embedded authorization server](../guides-vmcp/authentication.mdx#embedded-authorization-server)
 - For a similar configuration pattern using token exchange, see
   [Configure token exchange](./token-exchange-k8s.mdx)
 - For detailed Cedar policy syntax, see