If you’ve got OAuth working on your MCP server and you’re wondering whether what you shipped is actually safe to put in front of real users, this tech talk is for you.
Most “MCP auth” content stops at the happy path: token in, tool runs, you’re done. But the MCP spec, the Apollo docs, and the security researchers all agree that the default OAuth setup most people ship has three real problems hiding in it. None of them break the demo. All of them matter the moment you have actual users, multiple tools with different risk levels, or a security team that reads specs.
In one hour, we’re going to take a working OAuth-protected Apollo MCP Server — the kind you probably already have — and walk through exactly what’s wrong with it, why, and what to do about it. You’ll see the confused-deputy attack run live against a server that “passed” the OAuth tutorial, then watch us fix it with config changes you can make tomorrow. You’ll configure per-tool scopes so that a read tool and a write tool require different permissions, and watch Claude correctly trigger a step-up flow when it hits the boundary. And you’ll build the token-exchange pattern that the MCP spec is pushing the whole ecosystem toward — using the router extensibility hook Apollo just shipped — so you’re not waiting on a future Apollo release to get there.
You don't need to be a security expert. You do need to have set up OAuth on an MCP server before. If you haven't, Getting Started with MCP Server Auth, is the prerequisite. Bring the laptop you'd use to deploy the real thing.
Meet your speakers
