Audience, scopes and downstream credentials

The mechanism

A bearer token is authority intended for a particular recipient and purpose. The MCP server must validate that the token is meant for it, rather than accepting any token that happens to have a familiar issuer. Resource indicators help bind the authorization request to the intended MCP resource.

Do not pass the incoming token to an unrelated downstream API. That API is a different audience and often requires a separately obtained credential with its own scope. Token passthrough blurs accountability and can expose a credential to a service it was never intended to reach.

Within ParcelOps, authentication establishes the caller. Scope checks decide whether reading incidents is allowed. Object checks decide which incidents and fields the caller can read. All three gates matter; a valid token with incident:read need not grant access to every tenant.

Worked example

This is a synthetic claim-review table, not a signed JWT and not a token validation implementation. Production validation belongs in a maintained library and configured trust policy. Never accept these plain values as proof of authentication.

Case A: issuer expected, audience ParcelOps, scope incident:read -> check object grant
Case B: issuer expected, audience another API -> reject token
Case C: issuer expected, audience ParcelOps, scope profile -> deny incident read
Case D: expired credential -> require valid authentication
Case E: valid credential, another tenant's incident -> deny object access

Practice: predict, inspect, explain

Offline exercise. For each case, identify the layer that should reject the request and the safe user-facing response. Then draw a downstream incident API with its own audience and explain how the MCP server obtains appropriately scoped access without forwarding the incoming token.

Expected observation: no amount of prompt instruction fixes a wrong-audience token. The authorization decision must occur before a handler returns private data. Keep error distinctions useful without disclosing token contents or another user’s object existence.

Troubleshooting and trade-offs

If a server works only with an administrator token, investigate the missing narrow grant rather than normalizing broad access. If logs include bearer tokens or authorization codes, remove that logging path and follow the organization’s credential incident process. Exact issuer validation matters: do not normalize or substitute an issuer merely because its hostname looks related.

Interview practice

Completion check

Reject wrong-audience, insufficient-scope and foreign-object cases at their respective boundaries.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Security considerations
• Official documentation: Index
• Official documentation: Security best practices