Your remote MCP server fronts three downstream SaaS APIs — how do you design its credentials?

## The constraint that determines the architecture MCP revision 2026-07-28 requires audience-bound tokens and forbids token passthrough. The token a client presents was minted for *your* MCP server as its audience; it is not spendable anywhere else, and you must not try. That single rule settles the outbound question before design starts: your server is a credential *boundary*, and every upstream call is made with something your server holds. That is not a limitation to work around. It is what lets you put policy between the caller and three vendors who have no idea about each other. ## Two credential models, chosen per upstream **Per-user delegated access.** The user separately authorizes each SaaS, and your server stores that grant keyed to the user's identity. Access matches what that person can do in the vendor's product, the vendor's audit log names them, and revoking their access there revokes it here. The costs are real: a linking flow per user per vendor, refresh-token storage that is now a high-value target, and users who are half-linked at any given moment. **Service-identity access.** Your server holds one credential per upstream and calls with it. Simple to operate, but every access decision moves into your server — the vendor sees one caller and can no longer distinguish who asked. That is acceptable when the upstream data is genuinely shared by all callers, or the vendor offers no per-user model, and unacceptable where the upstream enforces per-user visibility you would then be silently flattening. Deciding per upstream rather than uniformly is the mark of the senior answer. A shared reference catalogue and a customer CRM do not deserve the same model. ## Designing your own scope vocabulary Callers authenticate to your MCP server, so the scopes on that token are *your* contract, not a mirror of three vendors' taxonomies. Two failure modes bracket the good design: - One scope for everything. Step-up becomes meaningless and every token is maximally powerful, so a leaked token is a full compromise. - One scope per tool. Consent screens grow to thirty lines that nobody reads, and the effective consent is worse than with five meaningful ones. Group by blast radius instead: read versus write, and per data domain, so that each scope maps to a sentence a user can evaluate. Then map scopes to upstream capability inside the server, and make the mapping the reviewed artifact — that mapping *is* your authorization model. Since a server's tool set may vary by the authorization presented (though never per connection), the same design decides what a narrow token even sees in `tools/list`. ## Blast radius and isolation Ask what one compromise costs. A single service credential per upstream with full privileges means a compromise of the MCP server yields full access to three products. Reduce it deliberately: request the narrowest upstream scopes that make your tools work, prefer short-lived credentials your server refreshes over long-lived static keys, and keep the credential store outside the process image so a code-execution bug does not immediately yield the secrets. If one upstream is dramatically more sensitive than the others, consider whether it belongs behind the same MCP server at all. Splitting it into a separate server with its own audience and its own tokens is often cheaper than defending a single server that holds everything, and it lets a user grant one without the other. ## Rotation and revocation as routine operations Design for both from day one. Rotation should overlap — the server accepts and uses a new upstream credential while the old one is still valid — so it is a normal deploy rather than a coordinated outage. For delegated grants, decide what happens when a refresh token is rejected: the tool should surface a re-link prompt through the host rather than fail opaquely, because the user is the only one who can fix it. On the inbound side, remember that MCP is stateless after 2026-07-28: there is no session to invalidate, so revocation is entirely a property of the token and of your validation path. If you cache validation results, cache them briefly, or a revoked token stays alive in your cache long after the authorization server disowned it. ## Consent and observability The user consented to your MCP server, and probably to each SaaS separately during linking. They did not consent to a tool that quietly reaches into a third product; make what a tool touches legible in its description and keep the surprising combinations out of one tool. On the operations side, log the caller identity, the tool, and which upstream identity was used — without that third field, an incident on the vendor's side cannot be traced back through your server to a person. ## What a strong answer sounds like Name the passthrough constraint first, then choose delegation versus service identity per upstream with reasons, then defend your scope granularity in terms of blast radius, then say how rotation, re-linking and revocation work operationally. An answer that stops at "store the API keys in a vault" has solved storage and skipped the authorization design.