Skip to main content
Tally runs a standard OAuth 2.1 + PKCE authorization server so MCP hosts and other clients can connect to a workspace without a user pasting a long-lived tly_… API key. It implements authorization-server metadata (RFC 8414), dynamic client registration (RFC 7591), protected-resource metadata (RFC 9728), and token revocation (RFC 7009). Most users never touch these endpoints directly — their host (e.g. Hermes) drives the flow. See MCP server → Authentication for the user-facing setup. This page documents the protocol for anyone wiring a new host or debugging.

Discovery

The authorization-server document advertises every endpoint and capability:

Scopes

A token is issued the intersection of the requested scopes and what the client registered. Moving money (POST /v1/payments) requires wallet:transfer; read endpoints work with any granted scope.

Flow

1

Register (once)

Public PKCE clients self-register. Redirect URIs must be https or loopback http (127.0.0.1 / localhost) per RFC 8252. No client secret is issued — PKCE is the proof-of-possession.
2

Authorize

Send the user to the authorization endpoint with a PKCE challenge. They sign in to Tally and pick the workspace, mode, and agent to authorize.
On approval Tally redirects to redirect_uri?code=tly_oac_…&state=…. On denial it returns ?error=access_denied.
3

Exchange the code for tokens

Use the access token as a normal bearer credential against /v1/*:
/v1/me is the source for a host’s whoami — everything it returns is non-secret (no token), so it’s safe to display or log. It answers “which workspace / agent / wallet am I connected as, with what scopes, and when does this connection expire?”.
4

Refresh

Access tokens last one hour. Exchange the refresh token for a new pair before it expires — refresh tokens rotate on every use, and reusing an already-rotated refresh token revokes the whole session (token-theft defense).
5

Disconnect / switch accounts

Revoking either token tears down the entire session (access + refresh):
To switch workspaces, revoke and re-run the authorize flow, choosing a different workspace on the consent screen.

Token reference

Only SHA-256 hashes of tokens and codes are stored server-side — the same model as API keys.

Security notes

  • PKCE is mandatory (S256 only; plain is rejected). There are no confidential clients and no client secrets.
  • Redirect URIs must be https or loopback http (127.0.0.1 / localhost). https URIs are exact-matched against the registration; loopback URIs match on host + path and accept any port (RFC 8252 §7.3), so CLI clients can bind an ephemeral port at request time.
  • Authorization codes are single-use and expire in 60 seconds.
  • Refresh-token rotation with reuse detection: a replayed refresh token revokes the whole grant family.
  • Account-scoped: a token only ever sees the workspace + mode the user chose on the consent screen. Spending stays bounded by each agent’s on-chain permission caps regardless of scopes.
  • The token endpoints are rate-limited and never cache responses.