Skip to main content
Version: 1.9.0

Let DVARA get OAuth tokens for MCP servers and A2A agents

Many MCP servers and A2A agents accept only short-lived OAuth access tokens. If you store such a token in DVARA, it stops working when it expires, and someone has to replace it by hand.

From 1.9.0, DVARA can get the token itself. You give it the server's token endpoint and a client id and secret. DVARA asks for a token with the OAuth 2.0 client credentials grant, uses it until shortly before it expires, and then asks for a new one.

What you set​

On the MCP server's page or the A2A agent's page in Flightdeck, fill in the OAuth Client Credentials section:

FieldWhat it is
Token URLThe authorization server's token endpoint. It must start with https://.
Client IDThe client id the authorization server gave you.
Client Secret ReferenceThe secret key of a credential on the Credentials page that holds the client secret. You never type the secret itself here.
Client AuthenticationHow DVARA sends the client id and secret: in a Basic header (the default) or in the request body.
ScopesOptional. The scopes to ask for, separated by spaces.
AudienceOptional. For authorization servers that want an audience value.
ResourceOptional. The address of the server the token is for (RFC 8707).

Leave Credential Reference empty: a server or agent that uses OAuth has no stored credential. Leave every OAuth field empty to turn it off.

For an MCP server, the token goes where the server's upstream authentication says: as a bearer token, or in a named header such as X-API-Key.

For an A2A agent, choose the OAUTH2 or OPENID_CONNECT auth scheme. If you leave Token URL empty, DVARA takes it from the client credentials flow in the agent's Agent Card when you save. The token is sent as a bearer token on every kind of call: messages, streams, task calls and the extended Agent Card.

How tokens are kept​

  • A token lives only in the memory of the gateway that asked for it. It is never written to a database, a log, a record or an export.
  • It is used until 30 seconds before it expires. Then DVARA asks for a new one.
  • When many calls need a new token at once, DVARA asks for it once.
  • If you change the client secret on the Credentials page, the next call asks for a new token with the new secret.

When no token can be obtained​

DVARA refuses the call. It does not fall back to a stored token or to the caller's own token, and nothing is sent to the server or agent. The caller gets MCP_UPSTREAM_OAUTH_FAILED or A2A_UPSTREAM_OAUTH_FAILED (502), with the reason: the client secret could not be found, the token endpoint could not be reached or refused (its OAuth error code, such as invalid_client, is shown), or its answer held no usable bearer token.

The token endpoint's address is checked like every address DVARA calls, and redirects are not followed.

What the records show​

  • A refused call is recorded with its reason, never a token or a secret.
  • Each new token is recorded by its fingerprint, so you can see when tokens were renewed without the token itself ever being kept.
  • Saving a server or agent records the token URL, client id, scopes, audience and resource. Pointing an MCP server at another client secret, or rotating that secret on the Credentials page, is recorded with fingerprints.
  • An export writes the client secret's reference as ***. Importing the file back keeps the reference you had.

Who can set it​

Platform administrators and workspace administrators can both set it. The client secret must be a credential that belongs to the server's or agent's workspace.

The client credentials grant is for a STORED server or agent, where DVARA acts as itself. For a DELEGATED one, which acts for the caller, the same fields with the Token exchange grant trade the caller's token for one made for the upstream: see Exchange a caller's token. Access on behalf of a user who signs in to the upstream service once is planned separately.