Token Vault is now an OAuth 2.1 authorization server for MCP
TL;DR
- Token Vault is now a full OAuth 2.1 authorization server for MCP — Claude, ChatGPT, and Cursor connect with zero pasted keys.
- One command to set up; the client discovers, registers, and authenticates itself via standard RFCs.
- Sessions expire hourly, re-check the agent on every refresh, and can be killed instantly — and your credentials still never touch Token Vault.
Until now, wiring an MCP client to Token Vault meant creating an agent in the console, copying its tvagent_ key, and pasting it into a config file. It works, but it is exactly the pattern Token Vault exists to kill: long-lived secrets sitting in plaintext config.
As of this release, Token Vault is a real OAuth 2.1 authorization server — and the protected resource it guards. Any client that implements the MCP authorization spec can connect with no credentials at all:
claude mcp add --transport http token-vault \
https://api.tokenvault.uk/api/agents/mcpThat is the whole setup. Here is everything that happens after it — no step involves you copying a secret:
You sign in once, pick which agent identity the client should act as, and approve. The client walks away with a one-hour tvsess_ session token and a refresh token — no static key ever touches a config file.
Standards, not a bespoke flow
The gateway implements what the MCP authorization spec requires — and keeps going past the baseline:
| Standard | What it does here | Status |
|---|---|---|
| RFC 9728 + 8414 | Discovery via /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server | Required by MCP |
| OAuth 2.1 + PKCE | S256 only; single-use authorization codes that expire in 60 seconds | Required by MCP |
| RFC 7591 | Dynamic client registration — public clients only, no client_secret, ever | Recommended by MCP; required by ChatGPT connectors |
| RFC 7009 + 7662 | Token revocation and introspection | Beyond the MCP baseline |
Sessions you can kill
A tvsess_ is bound to one (user, agent) pair and expires after an hour. Refreshing it re-checks the agent every single time: suspend the agent in the console and the next refresh is refused. Grants and ABAC policies apply to OAuth sessions exactly as they do to static keys — same identity, same rules, different handshake.
Gate your own services with one HTTP call
The introspection endpoint uses a bearer-as-subject model: present a tvsess_, learn whether it is live and whether Token Vault's schedule policies currently allow it. That makes Token Vault an identity plane for MCP servers you host yourself:
curl -X POST https://api.tokenvault.uk/api/mcp-oauth/introspect \
-H 'Authorization: Bearer tvsess_...'
{"active": true, "agent_id": "…",
"authorization": {"allowed": true}}Attach a time_window policy to the agent and your gateway honors your schedule within 15 seconds — without implementing any policy engine.
Your credentials still never touch us
None of this changes the custody model. OAuth sessions are Token Vault's own tokens — proof of identity, not credentials. Your actual secrets live on your webhook, on your infrastructure, and are delivered directly from it to your agents. Token Vault routes, scopes, and audits access; it holds nothing worth stealing.
Full reference: OAuth 2.1 for MCP Clients · Endpoint Reference · Introspection & Gateway Gating