MCP Auth Patterns

Technical overview of authentication patterns for MCP servers that call Autodesk Platform Services APIs.

Scope

This document targets cloud-deployed (remote) MCP servers that communicate with MCP clients over the Streamable HTTP transport.

OAuth Terminology Refresher

OAuth defines four core roles. In the context of APS:

OAuth Role	Definition	APS Example
Client	The application requesting access to protected resources on behalf of the resource owner.	Your MCP server, a web app, or a desktop app registered on the APS Developer Portal.
Resource Owner	The entity capable of granting access to a protected resource (typically the end user).	An Autodesk user who owns designs, models, or project data.
Authorization Server	The server that authenticates the resource owner and issues access tokens.	APS Authentication API
Resource Server	The server hosting the protected resources, capable of accepting and responding to requests using access tokens.	APS API services such as Data Management / OSS, Model Derivative, or Design Automation.

Authorization in the MCP Specification (2025-11-25)

The MCP Authorization specification defines how MCP clients authenticate to MCP servers over HTTP-based transports. Key points:

Based on OAuth 2.1 with support for RFC 8414 (Authorization Server Metadata), RFC 9728 (Protected Resource Metadata), RFC 7591 (Dynamic Client Registration), and Client ID Metadata Documents.
Authorization is optional. When supported on HTTP transports, implementations SHOULD conform to the spec.
MCP servers advertise their authorization server via Protected Resource Metadata (RFC 9728), either through the WWW-Authenticate header on 401 responses or via a .well-known URI.
PKCE is mandatory (S256 challenge method) for public clients. See 11.4 Authorization Code Protection: "To mitigate this, MCP clients MUST implement PKCE... and MUST verify PKCE support before proceeding with authorization".
Resource Indicators (RFC 8707) MUST be included in authorization and token requests to bind tokens to the intended MCP server.

IMPORTANT: Token Passthrough is Explicitly Forbidden!

The MCP spec contains a critical prohibition on token passthrough:

"MCP servers MUST NOT accept or transit any other tokens." — MCP Authorization §9.2 – Token Handling

"If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client." — MCP Authorization §11.8 – Access Token Privilege Restriction

The Security Best Practices – Token Passthrough section elaborates on the risks: security control circumvention, accountability / audit trail issues, trust boundary violations, and future compatibility risk.

In practice, this means: an MCP server acting as a gateway to APS cannot simply forward the MCP client's access token to APS APIs. The MCP server must obtain its own, separate APS access token through one of the patterns described below.

Access Patterns for MCP Servers Calling APS APIs

The following patterns address the two-layer authentication challenge:

Layer 1 — MCP Client ↔ MCP Server: How the MCP client authenticates to the MCP server.
Layer 2 — MCP Server ↔ APS: How the MCP server authenticates to APS APIs.

The MCP server acts in a dual role:

As an OAuth resource server to the MCP client (Layer 1).
As an OAuth client to APS (Layer 2).

Pattern A: Server-to-Server (2-Legged OAuth)

Layer 1: Authentication between MCP client and MCP server is either omitted, or handled by a third-party IdP unrelated to APS, for example, GitHub OAuth.

Layer 2: The MCP server authenticates to APS using Client Credentials (2-legged OAuth) with its own APS client_id and client_secret.

When to use: When the MCP server only needs to call APS APIs that support 2-legged OAuth, such as OSS, Model Derivative, or Automation API.

sequenceDiagram
    actor EndUser as User
    participant Client as MCP Client<br />(e.g., Claude)
    participant MCP as MCP Server
    participant APS_Auth as APS Auth Server
    participant APS_API as APS Resource Server<br />(e.g., Model Derivative)

    Note over Client,MCP: Either no auth, or 3rd party auth
    EndUser->>Client: "Get the metadata of my Revit model"
    Client->>MCP: Call tool
    MCP->>APS_Auth: 2-legged OAuth flow
    APS_Auth-->>MCP: APS access token
    MCP->>APS_API: API call + Authorization: Bearer 
    APS_API-->>MCP: API response
    MCP-->>Client: Tool response
    Client-->>EndUser: Result

Pros:

Simple setup; no user interaction required at the APS layer.

Cons:

Only works with APIs that accept 2-legged tokens; all API calls run under the application's identity, not a specific user's identity.
2-legged OAuth is not recommended for new integrations — support may be restricted or disabled in the future. Prefer 3-legged OAuth or Secure Service Accounts where possible.

Pattern B: Secure Service Accounts

Layer 1: Authentication between MCP client and MCP server is either omitted, or handled by a third-party IdP unrelated to APS, for example, GitHub OAuth.

Layer 2: The MCP server authenticates to APS using Secure Service Accounts. SSA provides a service account identity that can act as a "virtual user" for APIs that normally require 3-legged OAuth.

When to use: When the MCP server needs to call APS APIs that require 3-legged OAuth (user context) but a real interactive user login is not feasible.

sequenceDiagram
    participant EndUser as End User
    participant Client as MCP Client<br />(e.g., Claude)
    participant MCP as MCP Server
    participant APS_Auth as APS Auth Server
    participant APS_API as APS Resource Server<br />(e.g., AEC Data Model)

	Note over Client,MCP: Either no auth, or 3rd party auth
    EndUser->>Client: "List ACC projects"
    Client->>MCP: Call tool
    MCP->>APS_Auth: Exchange assertion (SSA's private key) for APS access token
    APS_Auth-->>MCP: APS access token (user-context, service account)
    MCP->>APS_API: API call + Authorization: Bearer 
    APS_API-->>MCP: API response
    MCP-->>Client: Tool response
    Client-->>EndUser: Result

Pros:

Enables access to APIs that require user context (3-legged) without interactive browser login.

Cons:

The end user cannot access their own data — only data that the service account owns or has been explicitly shared with. The service account is a separate identity.
If the MCP server uses a single secure service account, and if all users invite the account into their projects, everybody will see everybody else's data.
Creating a separate service account per user probably not feasible.

Pattern C: Server-Initiated Login + APS 3-Legged OAuth

Layer 1: Authentication between MCP client and MCP server is omitted. The MCP client does not include any access tokens when communicating with the MCP server.

Layer 2: The MCP server initiates a standard APS 3-legged OAuth flow by providing the end user with a login URL. The user opens this URL in their browser, authenticates with Autodesk directly, and the OAuth callback redirects back to the MCP server, which captures the APS access token (and refresh token) and caches them in a per-user session.

The login URL can be delivered to the user through different mechanisms depending on MCP client capabilities:

As a link in a tool response — the simplest approach. The MCP server returns a tool result containing a login URL, and the MCP client presents it to the user. This works with any MCP client today, with no special capability requirements.
Via URL mode elicitation — a more structured approach introduced in the MCP 2025-11-25 spec. The server sends an elicitation/create request (or returns a URLElicitationRequiredError), and the client presents the URL with proper consent UI. This also provides a notifications/elicitation/complete callback so the client knows when the user has finished logging in. However, URL mode elicitation is still very new and not yet widely supported by MCP clients.

When to use: When the MCP server needs to access APS APIs on behalf of a specific user (user-context / 3-legged).

sequenceDiagram
    participant EndUser as End User
    participant Client as MCP Client<br />(e.g., Claude)
    participant MCP as MCP Server
    participant Browser as End User's Browser
    participant APS_Auth as APS Auth Server
    participant APS_API as APS Resource Server<br />(e.g., ACC API)

	Note over Client,MCP: No auth needed
    EndUser->>Client: "List *my* ACC projects"
    Client->>MCP: Tool call (no APS token cached for this user)
    MCP-->>Client: Tool result: "Please log in with your Autodesk account: <authorization-url>"
    Client-->>EndUser: Presents login link
    EndUser->>Browser: Opens login URL
    Browser->>APS_Auth: User logs in + consents
    APS_Auth->>MCP: 302 Redirect to MCP callback(authorization_code, state)
    MCP->>APS_Auth: Exchange temporary code for access token
    APS_Auth-->>MCP: APS access token + refresh token (user-context)
    MCP->>MCP: Cache tokens (bound to user session)
    EndUser->>Client: "OK, I've logged in. Try again."
    Client->>MCP: Retry tool call
    MCP->>APS_API: API call + Authorization: Bearer 
    APS_API-->>MCP: API response (scoped to user)
    MCP-->>Client: Tool response
    Client-->>EndUser: Result

Pros:

Available to all developers today — does not require the internal-only MCP Auth Server. Any developer with an APS app can implement this pattern.
User authenticates with their own Autodesk account, so unlike Patterns A and B, the MCP server can access the user's own data.
APS credentials never transit through the MCP client — the OAuth flow happens out-of-band in the browser, and the MCP server stores tokens server-side. This fully satisfies the MCP spec's token passthrough prohibition.
Standard APS 3-legged OAuth — no user impersonation, no token exchange, no service accounts. Uses the same well-understood flow that APS web apps already use.
No special MCP client capabilities required — the simplest variant (login link in a tool response) works with any MCP client. If the client supports URL mode elicitation, the flow can be enhanced with structured consent UI and completion notifications.

Cons:

The MCP server must be stateful — it needs to persist APS tokens per user session and handle refresh token rotation. This adds operational complexity compared to stateless patterns.
Requires a browser context — the user must be able to open a URL and complete an interactive login. This may not work in headless or fully automated environments.
Without URL mode elicitation, the retry is manual — the user must tell the MCP client to try again after logging in, since the client has no programmatic way to know the login completed. With URL mode elicitation support, the server can send a notifications/elicitation/complete notification to automate this.

⚠️ Security Note: Session Hijacking Risk

Pattern C requires the MCP server to cache APS tokens per user session, typically keyed by the mcp-session-id header. If an attacker can guess or obtain a valid session ID, they can make authenticated APS API calls on behalf of another user. Recommended mitigations:

Use cryptographically random session IDs — generate 128+ bits of entropy from a CSPRNG (e.g., crypto.randomUUID() or crypto.randomBytes(32).toString('hex')) to make brute-force guessing infeasible.

Bind sessions to a client fingerprint — at session creation, record a secondary identifier such as the client's IP address, TLS client certificate hash, or a custom header value. Reject subsequent requests that don't match the original fingerprint.

Enforce short session TTLs and rotate session IDs — expire sessions after a short inactivity window (e.g., 15–30 minutes) and periodically issue a new mcp-session-id in a response header while invalidating the old one, shrinking the attack window if a session ID leaks.

Rate-limit and monitor session lookups — track requests with invalid or unknown session IDs per source IP. A spike in failed lookups is a strong signal of enumeration attempts.

Consider signed, encrypted session tokens — instead of an opaque server-side session-to-token mapping, issue a session token that embeds the APS refresh token and user metadata, signed (e.g., HMAC) and encrypted (e.g., AES-GCM). This eliminates the server-side session store as an attack surface entirely. The tradeoff is that revocation requires maintaining a denylist for invalidated tokens.

Summary Comparison

	Pattern A 2-Legged OAuth	Pattern B SSA	Pattern C Server-Initiated Login + 3L OAuth
Layer 1 (Client↔Server)	3rd-party IdP (or none)	3rd-party IdP (or none)	3rd-party IdP (or none)
Layer 2 (Server↔APS)	Client Credentials (2L)	Secure Service Account	3-Legged OAuth via browser
User's own data?	No (app identity)	No (service account)	Yes
Availability	GA	GA	GA
Best for	OSS, Model Derivative, DA	APIs needing user context without interactive login	3rd-party MCP servers needing user-context APS access

Appendix: Future Patterns (MCP Auth Server)

The following patterns rely on Autodesk's MCP Auth Server (https://developer.api.autodesk.com/mcpauth/v1) — a purpose-built OAuth authorization server designed for MCP flows. The MCP Auth service implements the MCP authorization spec, including support for Client ID Metadata Documents, so no pre-registration of MCP client IDs is needed.

⚠️ The MCP Auth Server is currently only available for Autodesk MCP servers. These patterns are documented here to illustrate what could become available to third-party developers in the future.

Pattern D: MCP Auth Server + User Impersonation

Layer 1: The MCP client authenticates to the MCP server via the MCP Auth Server.

Layer 2: The MCP server calls APS APIs using 2-legged OAuth with the x-user-id header set to the user ID extracted from the MCP access token (Layer 1). This is the "user impersonation" pattern.

sequenceDiagram
    participant EndUser as End User
    participant Client as MCP Client<br />(e.g., Claude)
    participant Auth as MCP Auth Server
    participant MCP as MCP Server
    participant APS_Auth as APS Auth Server
    participant APS_API as APS Resource Server<br />(e.g., ACC API)

    EndUser->>Client: "Show my ACC projects"
    Client->>MCP: MCP request (unauthenticated)
    MCP-->>Client: 401 + WWW-Authenticate (resource_metadata)
    Client->>Auth: User logs in and gives consent
    Auth->>Client: Callback with authorization code
    Client->>Auth: Authorization Code + PKCE(client_id = "https://app.example.com/oauth/client-metadata.json")
    Auth-->>Client: MCP access token (contains user ID)
    Client->>MCP: MCP request + Authorization: Bearer 
    MCP->>MCP: Validate MCP token, extract user ID
    MCP->>APS_Auth: POST /authentication/v2/token{client_credentials, 2-legged}
    APS_Auth-->>MCP: APS access token (2-legged)
    MCP->>APS_API: API call + Authorization: Bearer + x-user-id: 
    APS_API-->>MCP: API response (scoped to user)
    MCP-->>Client: MCP response
    Client-->>EndUser: Result

Pros:

The Client ID Metadata Document support eliminates the need for MCP clients to pre-register with the MCP Auth Server — any MCP client with an HTTPS-hosted metadata document can connect.
User identity flows through both layers, enabling access to user-specific data.
Compared to pattern C, the user credentials are managed by the MCP client. The MCP server can be simplified/stateless.

Cons:

The MCP Auth service is currently only available for internal Autodesk applications.
2-legged OAuth is not recommended for new integrations — support may be restricted or disabled in the future.
User impersonation via x-user-id is considered weak — the header value could theoretically be spoofed by the MCP server or any intermediary, since there is no cryptographic binding between the user's identity and the APS token.

Pattern E: MCP Auth Server + Token Exchange (RFC 8693)

Layer 1: Same as Pattern D — the MCP client authenticates to the MCP server via the MCP Auth Server.

Layer 2: Instead of user impersonation, the MCP server performs an OAuth 2.0 Token Exchange (RFC 8693) to convert the MCP access token from Layer 1 into an APS access token. The token exchange is performed at the APS authorization server, which validates the MCP token and issues an audience-restricted APS token for the same user.

sequenceDiagram
    participant EndUser as End User
    participant Client as MCP Client<br />(e.g., Claude)
    participant Auth as MCP Auth Server
    participant MCP as MCP Server
    participant APS_Auth as APS Auth Server
    participant APS_API as APS Resource Server<br />(e.g., ACC API)

    EndUser->>Client: "Show my ACC projects"
    Client->>MCP: MCP request (unauthenticated)
    MCP-->>Client: 401 + WWW-Authenticate (resource_metadata)
    Client->>Auth: User logs in and gives consent
    Auth->>Client: Callback with authorization code
    Client->>Auth: Authorization Code + PKCE(client_id = "https://app.example.com/oauth/client-metadata.json")
    Auth-->>Client: MCP access token (contains user ID)
    Client->>MCP: MCP request + Authorization: Bearer 
    MCP->>MCP: Validate MCP token
    MCP->>APS_Auth: Exchange MCP access token for APS access token
    APS_Auth-->>MCP: APS access token (user-context, audience-restricted)
    MCP->>APS_API: API call + Authorization: Bearer 
    APS_API-->>MCP: API response (scoped to user)
    MCP-->>Client: MCP response
    Client-->>EndUser: Result

Pros:

More secure than user impersonation — the APS access token is cryptographically derived from the MCP token via a server-side exchange. There is no spoofable header; the APS authorization server validates the incoming token and establishes trust.
Client ID Metadata Document support (same as Pattern D) — no pre-registration needed.
Clean separation of token audiences aligns with the MCP spec's token passthrough prohibition.

Cons:

The MCP Auth service is currently only available for internal Autodesk applications.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MCP Auth Patterns

Scope

OAuth Terminology Refresher

Authorization in the MCP Specification (2025-11-25)

IMPORTANT: Token Passthrough is Explicitly Forbidden!

Access Patterns for MCP Servers Calling APS APIs

Pattern A: Server-to-Server (2-Legged OAuth)

Pattern B: Secure Service Accounts

Pattern C: Server-Initiated Login + APS 3-Legged OAuth

Summary Comparison

Appendix: Future Patterns (MCP Auth Server)

Pattern D: MCP Auth Server + User Impersonation

Pattern E: MCP Auth Server + Token Exchange (RFC 8693)

References

Uh oh!

Clone this wiki locally