Authdog
Log In
Back to journal

MCP default resource: when the client skips the audience

Some MCP clients omit the OAuth resource parameter. Set a default protected resource so tokens still name your MCP URL.

From the changelog: Default MCP resource for OAuth clients

Authdog Team

4 min read
Centered Authdog and MCP marks with an angled resource word plate on a grainy indigo wash with a constellation

Some MCP and desktop AI clients still behave like classic OAuth 2.0 apps: they complete login, they receive a bearer token, and they never send RFC 8707’s resource parameter. That is awkward on an MCP authorization profile where the access token’s audience is supposed to match the protected MCP origin—not a generic API identifier.

PropelAuth and others call this out explicitly for Copilot-style integrations. Authdog now supports the same escape hatch per environment: a default protected resource when MCP Auth is enabled, plus optional strict resource indicator mode when you would rather fail closed.

This note explains what shipped, how authorize and token apply the default, and how to configure it without weakening discovery for well-behaved clients.

What breaks without a resource

When a client requests mcp:* scopes, your resource server usually validates JWT access tokens with an aud (or resource indicator) that equals the MCP URL you published under protected-resource metadata. If the client omits resource at authorize and token time, the issuer may mint a token whose audience does not line up with your MCP server. The client looks “logged in”; tool calls still fail verification.

That failure mode is silent until someone decodes a token or watches 401s on /mcp.

Default resource on the authorization server

For each environment you can enable MCP Auth settings (Management GraphQL today; console settings tab is on the roadmap):

Setting Effect
mcpAuthEnabled Turn on default-resource and strict-mode behavior for this environment.
defaultResource HTTPS URL applied when resource is omitted on authorize and token requests.
requireResourceIndicator When true and no default is set, missing resource returns invalid_request.

Behavior in the issuer:

  1. Explicit resource wins. If the client sends an HTTPS resource URL, that value is used after validation.
  2. Otherwise, if MCP Auth is enabled and a default is configured, authorize and token handlers substitute the default before minting JWT access tokens (including client-credentials flows that target MCP scopes).
  3. Strict mode rejects the request when MCP Auth is on, there is no default, and the client omitted resource.

This does not remove the need for /.well-known/oauth-protected-resource on your MCP origin. Well-behaved clients should still discover scopes and the authorization server from that document. Default resource is a compatibility bridge, not a replacement for metadata.

Configure and verify

  1. Choose the canonical MCP URL for the environment (the origin your resource server expects in aud).
  2. Save settings via saveEnvironmentMcpAuthSettings (or the console once the Settings tab ships).
  3. From a test client, run the token grant without resource but with MCP scopes. Decode the access token and confirm aud equals your default URL.
  4. Repeat with resource set to a different HTTPS URL and confirm explicit value wins.
  5. Enable strict mode on a staging environment with no default; confirm missing resource fails fast with invalid_request.

For headless checks, use the same confidential or public MCP client you already registered—no special “default resource client” type.

Trust boundaries

  • Default resource applies only when MCP Auth is enabled on the environment. Other OAuth clients keep prior behavior.
  • The default must be HTTPS. HTTP resource indicators are rejected.
  • Strict mode is intentionally harsh: use it when every client in that environment should send resource, and you do not want silent opaque tokens.
  • Setting a default does not grant scopes or bypass consent. It only fixes audience binding for token verification.

Relationship to Agent Sign-In and Connected Apps

Agent Sign-In and Connected Apps are separate OAuth surfaces (agents as subjects vs human consent to third-party clients). Default resource is about human-delegated MCP OAuth to your tool server. Agent tokens and machine grants follow their own audience rules documented under Agent Sign-In.

Try it

Set a default on a non-production environment, connect a desktop client that omits resource, and call one tool. If verification passes, promote the same URL to production metadata and defaults together.

Release note: /changelog#2026-10-11-mcp-auth-default-resource. Broader October identity controls (devices, self-service Connected Apps) are in /blog/october-identity-and-mcp-controls.