MCP authentication & OAuth
Your MCP tools call real APIs, and those APIs want credentials. Elva secures that hop with a stateless token relay: it exchanges and holds tokens in memory to make the upstream call, and never persists your credentials to disk.
The runtime supports the auth every real API uses, wires up OAuth 2.0 and OpenID Connect for agents that speak them, and encrypts the tokens it hands back to clients like Claude so raw secrets never leave the server.
Relay, not vault. The MCP runtime exchanges and caches tokens in memory only. It does not store your API keys, client secrets, or passwords in any database. Restart the runtime and the token cache is gone.
Auth types Elva supports
Every hosted MCP server has an Authorization tab where you declare how the tools should authenticate to your upstream API. Pick one type per deployment.
Auth type | Value | What the caller supplies |
No auth |
| Nothing. Tools call the API directly. |
API key |
| The key value. Elva injects it as a header or query param, with a header name you set (default |
Bearer token |
| A token, sent as |
JWT |
| A signed token, sent as a bearer credential. |
Basic auth |
| Username and password, base64-encoded into |
OAuth 2.0 |
| Client ID + secret (client credentials) or username + password (password grant). Elva exchanges them for an access token. |
OpenID Connect |
| An issuer URL you configure. The user signs in at the provider; Elva completes discovery and the code exchange. |
For API key auth you also choose the placement: send it as a request header or a query parameter. For bearer and JWT you can set a custom label so the connect screen tells users exactly which token to paste.
OAuth 2.0 grant types
When you pick OAuth 2.0, Elva runs one of two grants against your token URL:
- Client credentials (default): Elva base64-encodes the client ID and secret, POSTs
grant_type=client_credentialsto your token endpoint, and caches the returned access token. - Password: Elva POSTs
grant_type=passwordwith the username, password, and any scopes, then caches the token.
Authorization code is not yet supported end to end. The runtime and connect form recognize the authorization_code grant but return "Authorization code flow is not yet supported" instead of completing it. Use client credentials or password for OAuth 2.0 today, or OpenID Connect when your provider supports discovery.
How the OAuth relay works
For Claude custom connectors, the runtime speaks full OAuth 2.0: metadata discovery, dynamic client registration, and PKCE. The agent never sees the real upstream credential. It receives an opaque, encrypted envelope, and the runtime unwraps it only at call time.
On this page
- MCP authentication & OAuth