GLOSSARY · /GLOSSARY/OAUTH-PKCE

OAuth 2.1 PKCE Flow

When building AI agents that act on a user's behalf, you must grant them secure access to third-party accounts. For interactive integrations, the OAuth 2.1 PKCE flow guarantees that authorization codes cannot be intercepted, keeping user data secure. wmcp.sh handles the complexity of this handshake at the edge.

Why static keys aren't enough for interactive applications

Many developers mistakenly use static tokens for everything. However, a strict distinction must be drawn: for static, backend-only credentials (like a Discord bot token for Acme Corp), you should always use an encrypted credentials vault. But for user-facing, interactive OAuth flows—such as prompting a user to sign in via Google, GitHub, Slack, Notion, or Linear—you must utilize an OAuth 2.1 PKCE proxy.

PKCE (Proof Key for Code Exchange) solves a specific vulnerability where malicious apps running on the same device intercept the authorization code. By generating a dynamic code_verifier and its hashed code_challenge, PKCE ensures that only the application that initiated the request can exchange the code for an access token. (Note: wmcp.sh is not affiliated with Google, GitHub, Slack, Notion, Linear, Discord, or any other mentioned organizations.)

Executing the PKCE challenge

// 1. Generate a secure random string (code_verifier)
const verifier = generateRandomString(43);

// 2. Hash it with SHA-256 (code_challenge)
const challenge = base64UrlEncode(sha256(verifier));

// 3. Direct user to the authorization URL (e.g., Slack or Notion)
const authUrl = "https://provider.example.com/auth" +
  "?client_id=YOUR_CLIENT_ID" +
  "&response_type=code" +
  "&code_challenge=" + challenge +
  "&code_challenge_method=S256";

// 4. Once the code is returned, wmcp.sh proxies the token exchange
// passing the original verifier to prove identity, ensuring sub-100ms validation.

Securing Agent Auth with wmcp.sh

CapabilityStandard ImplementationWith wmcp.sh Proxy
Interactive OAuth Auth⚠️ Vulnerable if client_secret is exposed in SPA.✅ True OAuth 2.1 PKCE proxy flow.
Static Key Security❌ Using PKCE incorrectly for bot tokens.✅ Encrypted credentials vault for static keys.
Token Refresh Latency⚠️ 500ms+ roundtrips to central auth servers.✅ Sub-100ms edge token refresh.
Context Caching❌ No caching of auth-gated schemas.✅ Secure short TTL (~1s) schema caching.

Common questions.

Should I use PKCE for my Discord bot?

No. Discord bot tokens are static server-to-server credentials. You should store those in an encrypted credentials vault. PKCE is designed exclusively for interactive OAuth flows where a user explicitly grants permission via a browser.

What is S256?

S256 refers to the SHA-256 hashing algorithm. In the PKCE flow, the code_challenge is typically the SHA-256 hash of the code_verifier, Base64Url encoded. The auth server performs this same hash during the token exchange to verify identity.

Does this slow down agent execution?

The initial auth flow happens once. Subsequent API calls use the access token. With wmcp.sh deployed at the edge, token validation and refresh cycles maintain sub-100ms latency, ensuring agent reasoning is never bottlenecked by auth.

Need this done for you?

Skip the wiring — we build, deploy, and monitor.

Custom adapter + hosted MCP at mcp.yourbrand.com + verified badge. Pricing: Starter $499 one-time, Managed Retainer $999/mo, or Enterprise $4,999+/mo.

See /managed → Submit (free)