Overview

K-AI exposes three auth surfaces, one per caller type. Backend pipelines use static instance-id + api-key headers on the KAI Instance API. MCP clients and custom user-level integrations use OAuth 2.1 (Authorization Code + PKCE + Dynamic Client Registration). Browser frontends running under .kai-studio.ai use the kai_auth HttpOnly cookie. OAuth 2.1 and cookies share the same authorization server (https://auth-api.kai-studio.ai) — a token issued via either surface is accepted by both the K-AI Audit and K-AI MCP APIs.

Choose your auth

Caller type	Auth	Page
Backend pipeline ingesting documents	instance-id + api-key headers	Instance API keys
MCP client (Claude Desktop / Cursor / Le Chat) or custom user-level integration	OAuth 2.1 (Bearer JWT)	OAuth 2.1
Browser frontend on .kai-studio.ai	kai_auth HttpOnly cookie	Cookies

The decision rule is straightforward: a machine-to-machine pipeline with no end-user identity uses Instance API keys; anything acting on behalf of a human user — whether an MCP client or a custom integration — uses OAuth 2.1; a first-party browser app reuses the cookie set after login.

Where to next

• Instance API keys — static credentials for ingestion pipelines on https://api.kai-studio.ai. One key, one instance, no user identity.

• OAuth 2.1 — full Authorization Code + PKCE flow with Dynamic Client Registration. Includes Microsoft SSO behaviour and the end-to-end sequence diagram.

• Cookies — kai_auth HttpOnly cookie semantics: properties, sliding refresh, logout, cross-subdomain SSO.