Skip to lesson

AnthropicClaude Certified Architect – Professional2026-103.2 Analyze authentication and authorization requirements to identify security gaps

Review remote OAuth beyond successful sign-in

Completed by the knowledge check

Learning objective

Assess authorization for remote MCP servers and connectors: OAuth-based flows, scopes, and consent.

Core idea

A completed OAuth sign-in is not sufficient proof that a remote tool integration is correctly authorized. You must establish which client obtained consent, which server the token is for, what operations its scopes permit, and which component refreshes it.

The Model Context Protocol (MCP) authorization specification defines the protocol roles. Anthropic’s Messages API MCP connector defines one product integration with a narrower responsibility: it accepts a token supplied by your application. Review the protocol and the connector separately before approving an enterprise access path.

How it works

Identify the OAuth actors and trust transitions

For protected HTTP-based MCP access, the server acts as an OAuth resource server. The MCP client obtains access for a resource owner through an authorization server. Authentication to that authorization server establishes identity; the grant and the protected resource’s checks determine the access that follows.

MCP authorization is optional at the protocol level. For HTTP transports, implementations that support authorization SHOULD conform to the specification. Stdio deployments SHOULD NOT follow this flow and should obtain credentials from the environment. Do not infer that every MCP connection performs browser-based OAuth.

Protected servers publish OAuth Protected Resource Metadata. A 401 challenge can identify it through WWW-Authenticate and resource_metadata; the client discovers authorization-server metadata before initiating authorization. Verify that discovery directs the client to the intended issuer, not merely to an endpoint supplied by untrusted tool content.

The authorization flow uses Proof Key for Code Exchange (PKCE): the authorization request includes code_challenge, and token redemption uses code_verifier. It also includes resource to identify the target MCP server. Review that value at both authorization and token exchange rather than accepting a token that happens to work somewhere in the enterprise.

Revision 2026-07-28 requires clients to record the expected issuer before redirecting. If an authorization response contains iss, the client compares it with that recorded issuer before redeeming the code. If metadata advertises authorization_response_iss_parameter_supported: true and iss is absent, the response is rejected. If neither advertisement nor iss is present, the client can proceed under the specified rule; do not turn a conditional requirement into an unconditional missing-field rejection.

The MCP server’s 401 challenge starts discovery; the client then records the issuer, sends resource with both the authorization request and the token redemption, and checks iss before redeeming the code.

The challenge starts discovery, resource is sent at both steps, and iss is checked before the code is redeemedThe MCP client attempts protected access and the MCP server answers with a 401 challenge naming resource_metadata. The client discovers authorization-server metadata and records the expected issuer. It sends the authorization request with code_challenge and resource, compares the iss in the authorization response with the recorded issuer, and only then redeems the code with code_verifier and resource.Authorization serverMCP serverMCP clientrecord expected issuercompare issprotected MCP access401 · resource_metadatadiscover metadatacode_challenge, resourceresponse · isscode_verifier, resource

Review audience and scope enforcement

The MCP server must validate that an access token was issued for it as the intended audience. It must not accept or transit a token intended for another resource. Invalid or expired tokens produce HTTP 401; invalid scopes or insufficient permissions produce 403. A token accepted by the wrong resource is a security defect even when its signature is valid.

Do not forward the MCP client’s bearer token unchanged to a downstream business API. The server needs the appropriate separate downstream authorization, rather than treating one token as a universal enterprise credential. Token passthrough undermines the audience boundary and makes the downstream access trail harder to interpret.

Scopes express granted capabilities, but they do not replace resource-specific authorization. A token with a read scope might still lack access to the particular customer record. Keep that entitlement check in the resource service; see 3.2.2.

The specification prioritizes the scope in the initial WWW-Authenticate challenge. If it is absent, the client uses scopes_supported from Protected Resource Metadata, omitting the request’s scope parameter if that field is undefined. The challenged scope set need not be a subset of scopes_supported; treat the challenge as authoritative for the operation rather than assuming a fixed global catalog.

For step-up access, a 403 can include error="insufficient_scope" and the required scope. Additional access requires the authorization flow and user consent, not a retry that silently adds broader permissions. Evaluate whether the requested elevation matches the business action before seeking it.

A proxy connecting multiple MCP clients to a third-party service can become a confused deputy when existing third-party consent lets another client obtain access without its own approval. The MCP security guidance requires per-client consent: a registry of approved client_id values per user, checked before starting the third-party authorization flow.

The MCP-owned consent page identifies the requesting client, requested third-party scopes, and registered redirect_uri. It also needs cross-site request forgery protection and protection against framing. This is consent to a particular client’s access path, not merely recognition that the person once signed in to the underlying service.

Retain which client and scopes the user approved. A tool execution confirmation and an OAuth grant have different purposes: approving one proposed tool call does not automatically approve a broader client grant. The integration owner must be able to explain both records.

Apply the connector’s actual boundary

The Messages API MCP connector is beta and uses anthropic-beta: mcp-client-2025-11-20 for its documented base interface. It connects to publicly reachable HTTP servers using Streamable HTTP or SSE, and supports tool calls rather than the full MCP feature set. It is not eligible for Zero Data Retention. Its documented platform list includes Claude API, Claude Platform on AWS, and Microsoft Foundry; do not infer availability on other platforms.

Your application obtains and refreshes the token, then sets mcp_servers[].authorization_token. The server definition names the destination with url and name; a tools entry with type: "mcp_toolset" and mcp_server_name selects its tools. For a narrow tool surface, use default_config.enabled: false and enable approved tools in configs. These client-side controls do not replace the server’s token and resource checks.

Claude Code itself acts as the OAuth client for a configured remote HTTP server: /mcp or claude mcp login <name> runs the flow, and Claude Code stores tokens securely and refreshes them automatically. Pin the approved scopes with oauth.scopes, a space-separated string; noninteractive claude -p and Agent SDK runs require sign-in beforehand because they cannot run that interactive flow. For claude.ai connectors delivered to cloud sessions, the session proxy instead authenticates with the authorization granted in claude.ai; reconnect there when authorization needs renewal.

Test consent and audience isolation separately from tool invocation, with accountable owners.

Key distinctions and trade-offs

A broad initial scope grant reduces later consent interruptions but increases authority and the impact of misuse. Incremental elevation keeps initial access narrower but introduces an authorization interruption when work crosses that boundary. Choose scopes according to the workflow, not the largest grant the provider permits.

The Messages API connector reduces client implementation work but leaves OAuth lifecycle work with the application. A custom client can own that lifecycle directly, at the cost of protocol implementation and security maintenance. Neither arrangement removes server-side authorization.

Architecture / decision scenario

A retail assistant reads inventory and can request supplier-order changes. Its initial workflow is read-only; order changes require a buyer’s approval. The integration team proposes one shared token with both capabilities so that all 400 store users avoid consent interruptions.

The architect rejects it because the shared grant obscures whose authority permits an order change. The application obtains per-user read access for the intended MCP resource and passes it through authorization_token. Its toolset initially disables write tools. When an authorized buyer requests a change, the application handles the documented insufficient-scope flow and obtains explicit approval for the necessary elevation.

An MCP proxy fronts the supplier API. It checks its per-user client_id consent registry and uses separate downstream authorization. The security owner tests wrong-audience tokens, expired tokens, and a second client trying to reuse the first client’s consent. The application owner tests refresh and read-only operation after a rejected elevation. Successful inventory retrieval alone would satisfy none of those acceptance conditions.

Common exam traps

  • Assuming the Messages API MCP connector obtains or refreshes OAuth tokens.
  • Treating a valid signature as proof of the correct token audience.
  • Passing an MCP token unchanged to a downstream resource.
  • Equating tool enablement with server-side authorization.
  • Reusing third-party consent without per-client consent at a proxy.
  • Treating every 403 as a reason to retry with broader scopes automatically.

Where the exam guide differs

Note:

The exam guide names no MCP revision and was written while revision 2025-11-25 was published. This Bite cites revision 2026-07-28, a later revision whose authorization changes include response-issuer validation and issuer-bound persisted client credentials. It also deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, while retaining registration compatibility. The revision also reclassifies HTTP+SSE as Deprecated and directs migration to Streamable HTTP, although the Anthropic connector documents SSE support. Read an exam item about OAuth, scopes, or consent as an architectural requirement; use the cited revision’s rules when implementing that requirement rather than assuming the guide pins a protocol version.

What to remember

Review issuer, audience, scopes, and consent as separate checks. The application owns the Messages API connector’s OAuth lifecycle; the MCP server owns token validation and resource authorization. A proxy needs per-client consent and distinct downstream authorization.

Knowledge check

References