Per-User OAuth Across Many Tenants: MCP Authentication at Scale

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 23)

▶ Watch on YouTube & subscribe to The Stack Underflow

Say you’re building a tool that lets an agent pull tickets from a customer’s help desk. One customer, easy — drop an API key in an environment variable and call it a day. Now say you have four hundred customers, each with their own OAuth grant, their own token refresh cycle, and their own audit requirement, and three different agent surfaces (a chat UI, a Slack bot, an internal ops console) all need to make that same call on behalf of whichever user is currently logged in. Where does that authentication logic live? That question — asked plainly, with four tempting-sounding answers — is exactly what Domain 2 of the Claude Certified Architect exam tests, and it’s the tenth question in this practice set.

The one-sentence version: When a tool needs per-user OAuth across many tenants, put it behind an MCP server — one place owns the auth flow, the token store, and the audit trail, and every client just calls the tool.

The question

A tool must call a SaaS API with per-user OAuth across many tenants. Should it be built as an MCP server or an inline tool, and why?

• A) Inline — simpler
• B) MCP — it centralizes auth, multi-tenancy, and governance
• C) Neither; embed tokens in the prompt
• D) Only if the model is large

Pause here and pick an answer before you keep scrolling. This is Q10 of 10 in the D2 (Tool Design & MCP Integration) practice set — if you’re just landing on this page, the full exam guide has the five-domain map for context.

The answer

B — MCP. When authentication is per-user and the number of tenants is large, MCP is the architecture that centralizes auth, multi-tenancy, and governance in one place, instead of scattering that logic across every agent, every call site, and every codebase that needs to talk to the SaaS API.

The mechanism is about where the OAuth flow, the token store, and the audit log physically live. With an inline tool, “inline” means the OAuth handshake, the refresh logic, and the token storage get written directly into whatever codebase owns that particular agent. If three teams build three agents that all need the same ticketing-API access, you get three separate implementations of the same OAuth dance — three places tokens can leak, three places the refresh logic can silently break, three audit trails (or none).

An MCP server flips that. One server sits between the agents and the SaaS API. It owns the OAuth client registration, the per-tenant token vault, the refresh cycle, and the request log. Every agent — chat UI, Slack bot, ops console — talks to the same MCP server over the same protocol. The server resolves “which tenant, which user, which token” once, in one codebase, and the agents never see a raw credential at all.

INLINE (per-agent OAuth)                 MCP (centralized OAuth)
┌───────────┐  own OAuth flow            ┌───────────┐
│ Chat UI   │──┐                         │ Chat UI   │──┐
└───────────┘  │  token in code/env      └───────────┘  │
┌───────────┐  │                         ┌───────────┐  │   MCP protocol
│ Slack bot │──┼─→ SaaS API (x3 impls)   │ Slack bot │──┼─→ ┌─────────────┐
└───────────┘  │     tokens scattered    └───────────┘  │   │ MCP server  │──→ SaaS API
┌───────────┐  │     no shared audit     ┌───────────┐  │   │ • OAuth flow│
│ Ops console│─┘                         │ Ops console│─┘   │ • token vault│
└───────────┘                            └───────────┘      │ • per-tenant │
                                                              │   scoping   │
     3 codebases own OAuth                                   │ • audit log │
     3 places tokens can leak                                └─────────────┘
                                                          1 owner of auth + governance

This is the same “reuse across agents/teams → MCP server” logic from Same Tool, Three Agents: Inline Tool or MCP Server?, pushed one step further: it’s not just reuse, it’s reuse plus a security-sensitive concern (per-user identity across tenant boundaries) that genuinely benefits from having a single owner. Multi-tenancy makes centralization non-optional — a bug in tenant isolation, duplicated three times inline, is three separate incidents waiting to happen instead of one bug to fix in one place.

Why the other options fail

• A) Inline — simpler. Simpler for the first agent, yes. But “simpler” stops being true the moment a second agent needs the same access. You’re not choosing between simple and complex — you’re choosing between complex-once (MCP server) and complex-repeatedly (N inline OAuth implementations, N places to patch when a tenant revokes access or a token format changes).
• C) Neither; embed tokens in the prompt. This isn’t a lesser version of the right answer — it’s a security incident waiting to be filed. Prompts get logged, cached, sent to observability tools, and sometimes echoed back in model output. A per-tenant OAuth token embedded in a prompt is a credential sitting in plaintext in every place that prompt ever travels. Tokens belong in a secured vault behind a server boundary, never in the context the model reads.
• D) Only if the model is large. Model size has nothing to do with where authentication logic lives. This option is designed to test whether you’re pattern-matching “MCP” to “bigger, fancier setup” rather than understanding what MCP actually solves — protocol standardization and centralized service ownership, not model capability.

The concept behind it

Zoom out from OAuth specifically and the general rule is this: any concern that must stay consistent across multiple clients, and that carries real risk if it drifts, belongs behind a single server boundary — not duplicated inline. Authentication is the sharpest example because the cost of drift is a security bug, not just an inconsistent user experience.

A few properties make per-user, multi-tenant auth an especially strong case for MCP:

Notice this is the same decision diamond that shows up in MCP Explained on One Diagram and in the “expose tools across services” scenario from earlier in this series: ask whether a capability is reused across agents or teams, and whether consistency actually matters if it drifts. Auth nearly always answers yes to both. That’s why the exam leans on OAuth specifically to test the MCP-vs-inline decision — it’s the scenario where getting the architecture wrong has the highest blast radius.

One caveat worth keeping honest, echoed directly in the source material for this question set: this is guidance, not a hard rule. A single internal tool, one team, one tenant, no OAuth complexity — that can stay inline. The trigger for MCP isn’t “does this call an external API,” it’s “does auth need to be centralized, multi-tenant, and governed across more than one consumer.”

FAQ

Does MCP replace OAuth, or sit on top of it? MCP doesn’t replace OAuth — it’s the architectural layer where an OAuth implementation lives once instead of many times. The MCP server still performs a standard OAuth 2.0/2.1 flow against the SaaS provider; MCP just gives you one server process that owns that flow, the resulting tokens, and the mapping from “authenticated MCP session” to “which tenant’s token to use.”

What happens to per-tenant isolation if the MCP server itself is compromised? The MCP server becomes your single most security-critical component, which is exactly why it needs the same least-privilege and gating discipline covered in A Tool That Can Delete Prod: Designing Safe Destructive Tools — scoped tokens, tenant-boundary checks on every call, and an audit log that would catch cross-tenant access immediately. Centralizing auth concentrates risk in one place, but a well-secured single place beats three loosely-secured places.

Isn’t calling an MCP server extra latency compared to an inline function call? Yes, there’s a network hop that a same-process inline call doesn’t have. For a single-tenant, single-agent tool, that latency cost may not be worth paying. For multi-tenant OAuth specifically, the operational cost of not centralizing (drifted implementations, leaked tokens, inconsistent audit) almost always outweighs the added round-trip.

How does this interact with per-tenant rate limits on the SaaS API? Centralizing in an MCP server actually helps here too — one server can track and enforce per-tenant rate limits coherently, where three inline implementations would each need to independently discover and respect the same limits, usually inconsistently.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This closes out the Domain 2 (Tool Design & MCP Integration, ~18% of the exam) practice set. If you want the mechanism for the general MCP-vs-inline decision before auth enters the picture, read Same Tool, Three Agents: Inline Tool or MCP Server? first, then 40 Tools, Wrong Picks, High Latency: Scoping Tools Per Agent for what happens once you’ve centralized several capabilities behind MCP servers and need to scope which agent sees which ones. For the protocol fundamentals themselves, see MCP Explained on One Diagram. And for the full five-domain map of what else is on the exam, start with the Claude Certified Architect (CCA) Exam Guide. Exam logistics as of mid-2026 — Pearson VUE delivery, $125, retakes permitted, 60 questions in 120 minutes, a pass bar around 720/1000 across five domains — should always be verified against Anthropic’s official pages before you register. Browse all tutorials for the rest of the series.