Build on it

Authentication

Two ways in, one capability layer behind them. Agent clients use OAuth 2.1; backends use a scoped API key. Both are scoped to a single workspace and every call is audit-logged.

OAuth 2.1 for agents

The MCP server is an OAuth 2.1 resource. Clients that support it (Claude, ChatGPT, Cursor, VS Code) discover the authorization server, register dynamically, and run the standard sign-in. You never paste a key.

  • Dynamic Client Registration means the client registers itself; there is no app to create by hand.
  • PKCE (S256) protects the exchange.
  • Opaque, database-backed tokens (prefixed mcpat_) are revocable and carry no embedded claims. Each acts as an audit actor.

Discovery metadata is served live under /.well-known, so a compliant client needs only the server URL.

Scoped API keys for backends

For non-agent integrations, the parallel REST API at /api/v1/orchestrator uses Bearer auth with scoped keys issued in your HiringTest settings under Integrations. Scopes gate what a key can do, for example jobs:read, candidates:write, or the assessment scope. Issue the narrowest scope that works, and rotate by adding a new key before retiring the old one.

The cross-domain issuer note

The OAuth sign-in completes on the HiringTest origin where your session already lives, while the MCP resource is served on the orchestrator host. OAuth 2.1 allows this split: the protected-resource metadata advertises the authorization server, and the client follows it. If you are scripting against discovery directly, read the advertised authorization_servers value rather than assuming a single host.

Whichever path you use, the result is identical: a workspace-scoped actor whose every read and write lands in the same audit log as the UI. There is no elevated agent path. See Concepts for the graded-write model that applies on top.