MCP authentication & OAuth
Configure how your MCP server authenticates to the upstream API from its Authorization tab. The Elva gateway relays authenticated requests; your API remains responsible for user permissions and tenant isolation.
Elva supports API keys, bearer tokens, JWT, Basic authentication, OAuth 2.0, and OpenID Connect. OAuth-enabled clients can complete a browser sign-in flow before calling tools.
Credential handling depends on the authentication flow. Saved credentials and supported OAuth connection records are encrypted at rest. Access tokens may also be cached for reuse. Treat a connected MCP client as authorized to use the permissions granted by its upstream credentials.
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 | Configuration value | How it works |
No authentication | none | No upstream credential is added. Use only for intentionally public APIs. |
API key | api_key | Supply a key; configure the header or query parameter name and placement. |
Bearer token | bearer | Supply a token sent in the Authorization header. |
JWT | jwt | Supply a JWT sent as a bearer credential. |
Basic authentication | basic | Supply the upstream username and password. |
OAuth 2.0 | oauth | Configure the provider and supported grant: authorization code, client credentials, or password. |
OpenID Connect | openid_connect | Configure the issuer and complete provider discovery and browser sign-in. |
For API-key authentication, set the key name and whether it is sent as a header or query parameter. You can customize the credential label and the button label and URL that tell users where to obtain an API key. Use an HTTPS URL and do not include a key in that link.
OAuth 2.0 grant types
Choose the OAuth grant supported by your provider:
Grant | Use | Required setup |
Authorization code | Interactive sign-in and consent through the provider. | Authorization and token endpoints, client configuration, redirect URI, and scopes. |
Client credentials | A service authenticates with its own identity. | Token endpoint, client ID, client secret, and supported scopes. |
Password | A provider explicitly supports exchanging a username and password. | Token endpoint and the provider's required credential fields. Prefer authorization code for interactive sign-in. |
Register the redirect URI shown by Elva with your provider exactly. If sign-in fails, compare the redirect URI, issuer or endpoint URLs, requested scopes, and client settings. After changing authentication settings, reconnect your MCP client and verify a tool call.
How the OAuth relay works
An MCP client can discover Elva's OAuth metadata, register where supported, and complete a PKCE-protected authorization flow. The gateway uses the authorized upstream connection at tool-call time. Preview: compatible deployments can retain encrypted OAuth connection state and refresh tokens. Sign in again when the provider cannot refresh a connection.
On this page
- MCP authentication & OAuth