How Volcano Engine Secures MCP OAuth: Multi‑Layer Defense Against Token Theft

The article analyzes the OAuth security challenges posed by the open Model Context Protocol (MCP) ecosystem of Volcano Engine and presents a multi‑layered, depth‑defense solution.

Background: MCP OAuth openness and security challenges

MCP enables third‑party developers to seamlessly integrate their clients (e.g., IDE plugins, SaaS platforms) with the AI model ecosystem, fostering innovation but also exposing the platform to novel security risks. To support dynamic client registration, MCP adopts the OAuth 2.0 Dynamic Client Registration protocol (RFC 7591), allowing clients to obtain client_id and client_secret via a /register endpoint.

Core Risks

Risk 1: Malicious client intercepts authorization code

Attackers create a rogue MCP client, lure users to authorize, and capture the authorization code, which is then exchanged for an access token at the /token endpoint.

Victim initiates OAuth flow through the malicious client.

User is redirected to Volcano Engine’s consent page and grants permission.

The authorization server issues an Authorization Code and redirects it to the attacker‑controlled redirect_uri.

The attacker captures the code.

Using the captured code together with its own client_id and client_secret, the attacker calls /token to obtain an Access Token .

Impact: With the stolen token, the attacker can act on behalf of the user, read data, invoke paid services, or modify configurations.

Risk 2: Confused Deputy problem with malicious server

Even a trusted client can be compromised if it is configured with a malicious MCP server address. The client unknowingly forwards the user’s access token to the attacker‑controlled server.

User configures a legitimate client (e.g., Cursor) with a malicious server URL.

The malicious server directs the client to a legitimate Volcano Engine authorization endpoint.

After user consent, the token is returned to the legitimate client.

The client, acting as a “Confused Deputy,” forwards the token to the malicious server.

The malicious server extracts the token from the request.

Impact: Similar to Risk 1, but the attack bypasses client‑side compromise and steals the token during normal data exchange.

Risk 3: Token leakage and privilege abuse

Improper client storage: Tokens stored in plain text files, databases, or browser local storage can be exfiltrated if the device is compromised.

Log or transport exposure: Tokens printed in logs or sent over unencrypted channels.

Over‑privileged scopes: Tokens granted excessive permissions amplify damage when leaked.

Mitigation Strategies

Pre‑authorization double confirmation

Before redirecting back to the client, Volcano Engine’s consent page displays the target redirect_uri and the exact permissions requested, requiring the user to confirm a second time, thereby blocking phishing‑style attacks.

Token identity isolation

Access Tokens issued via MCP OAuth are strictly isolated from the main Volcano Engine login session. Even if the token is stolen, it cannot be used to access the user’s primary account on the Volcano Engine portal.

API‑level permission control (least‑privilege)

Each MCP service must register its required permissions at the API level, and every permission request undergoes security‑engineer review to ensure no excessive rights are granted.

Reject vague permissions: Disallow wildcards like * or Describe*.

Align permissions with functionality: Permissions must map to concrete features.

Enforce least‑privilege: Only the minimal set of scopes needed for the service is approved.

Conclusion

Facing the OAuth security challenges of an open MCP ecosystem, Volcano Engine adopts a “pre‑prevention, in‑process restriction, post‑incident fallback” strategy. The combined measures—double confirmation, token identity isolation, and strict API‑level permission control—preserve openness while safeguarding user assets and reinforcing the platform’s security governance.