Auth behind the gateway

OAuth passthrough

If your MCP server uses OAuth 2.1, it keeps working behind the gateway. The gateway forwards Authorization verbatim and rewrites your server's protected resource metadata so the client sees the gateway origin as the resource server.

One thing to check on your side: your server must accept the gateway origin as a valid resource and audience value. Set your server's canonical resource to the gateway URL. Audience checks must tolerate the trailing-slash variant of the resource URL, because clients send it both with and without the trailing slash.

Static header injection

If your upstream requires an internal secret (a shared key, a service token), add it under static headers on the Gateway tab. The gateway sets these headers on every request to your server, overriding anything the client sent, and they are never visible to your end users or stored in your captured telemetry.

Gateway-managed client keys

If your MCP server has no auth of its own, the gateway can add one. Switch the access mode to require a gateway client key, then create keys for the clients or teams that should have access. Each key is shown once.

Clients send the key as Authorization: Bearer spanlygw_.... The gateway validates it at the edge and strips it before the request reaches your server, so your server never sees the key. Revoking a key takes effect within about 30 seconds.