Skip to main content
ComplyHat uses OAuth 2.1 with Dynamic Client Registration (RFC 7591) backed by Supabase Auth OAuth Server. Every supported host (Claude Code, Claude Desktop, Codex Desktop, Codex CLI, OpenClaw, NemoClaw) handles the entire flow without setup on your side. You see one consent screen the first time you connect; the host does the rest.

​
What happens when you connect

1

Discovery

Your host fetches /.well-known/oauth-protected-resource to find the authorization server.
2

Registration and consent

The host registers itself via DCR; your browser opens to https://complyhat.ai/oauth/consent. Sign in, pick an organization, approve.
3

Token exchange

The host receives a bearer access token and calls https://complyhat.ai/api/mcp with Authorization: Bearer <token>. ComplyHat verifies the signature, iss, aud, and client_id against Supabase JWKS on every request.

​
Scopes

Hosts request the OIDC standard set: openid email. That is the only set the authorization server (Supabase Auth OAuth Server) issues today, and it is what /.well-known/oauth-protected-resource advertises: 
{
  "scopes_supported": ["openid", "email"]
}
Authorization is enforced at the organization layer, not at OAuth-scope granularity. Every ComplyHat tool call resolves the caller’s organization_id from their token’s sub claim and filters all data reads and writes through that org context. The same boundary the web dashboard uses applies to MCP , there is no second authorization layer to configure. If you’ve seen older docs referencing fine-grained scopes like wiki:write or models:read, those were planned for a future Custom Access Token Hook and are not currently issued by Supabase OAuth Server. They will reappear here only if and when that hook is enabled.

​
When auth fails

A request without a valid bearer token returns 401 Unauthorized with a WWW-Authenticate header per RFC 6750: 
WWW-Authenticate: Bearer realm="ComplyHat", error="invalid_token", resource_metadata="https://complyhat.ai/.well-known/oauth-protected-resource"
Spec-compliant hosts read resource_metadata, run discovery, and re-authenticate without further intervention.
Last modified on May 15, 2026