MCP OAuth resource indicator: is a token bound to the server?

For Sume the token audience is a single string: the OAuth resource audience is https://mcp.sume.com/mcp, and the authorization server is the MCP origin, not www or app.sume.com. The MCP 2026-07-28 release describes authorization hardening with RFC 9207 issuer validation.

What did the 2026-07-28 release change in auth?

The MCP release post lists RFC 9207 issuer validation, and says dynamic client registration is deprecated in favor of Client ID Metadata Documents. That is all the post snapshot I read says on auth, so this page does not describe further binding rules; the spec has the detail.

What is Sume's resource and issuer?

Sume's OAuth page lists the flow: the client connects to https://mcp.sume.com/mcp, gets protected-resource metadata where authorization_servers is the MCP origin, and is sent to https://mcp.sume.com/oauth/authorize. Two metadata documents are public.

Can the token be reused elsewhere?

Sume's credential safety notes say an MCP OAuth token is not a Sume API key, and that you should not forward it to third-party providers, store it in CLI config or paste it into prompts. sume login does not broker hosted MCP OAuth tokens. The docs do not say how the server enforces the audience beyond naming it, so do not assume more than the stated values.

What should a client check?

Use the exact resource string from the OAuth page, and do not point interactive clients at app.sume.com for MCP sign-in. Production is the only host customer configs should use.

What if my client sends me to the wrong site?

The OAuth page says authorization_servers in the protected-resource metadata is the MCP origin, not www or app.sume.com. If a client sends you anywhere else for MCP sign-in, stop: the documented authorize URL is https://mcp.sume.com/oauth/authorize and the consent page is on the same host.

The docs add that www.sume.com remains a secondary and deprecated authorization-server surface, and that the protected-resource metadata no longer advertises it. A client that follows the metadata will therefore land on the MCP host on its own.

How do I confirm the audience in practice?

Fetch the two public metadata documents listed above and compare them to what your client uses. The protected-resource document is the one that names the authorization server, and the OAuth page says that value is the MCP origin.

Then run the flow once and call mcp_health after sign-in. The playbook in Sume's docs says to confirm that authenticated.auth_source is mcp_oauth, which tells you the session is using the OAuth token and not an API key.