TigerTrust supports three authentication mechanisms depending on who is calling:
| Caller | Mechanism |
|---|
| Human user in a browser | Session cookie set after login |
| Server-to-server / CI | API key (ck_...) |
| Field agent | Agent key (ak_...) |
| Interactive sign-in | Google OAuth 2.0 |
API keys
API keys are the recommended way to call the API from scripts and integrations. They are generated per-workspace and carry a scope list.
Key types
ck_<64 hex> — client key. Use against the main REST API.
ak_<64 hex> — agent key. Used by field agents to connect through the Collector.
API keys are returned in full only once, at creation time. Store them in a secret manager immediately — they cannot be retrieved later.
Creating an API key
Go to Integrations → API Keys → New Key, or use the API. The API surface for key management is documented at API Reference.
Using an API key
Send the full key in the X-API-Key header (preferred) or in Authorization: Bearer <key>.
curl https://api.tigertrust.example.com/api/certificates \
-H "X-API-Key: ck_9f2a3b4c...7c4e"
Session cookies
After signing in through the login page, TigerTrust sets an httpOnly session cookie with a 7-day TTL. You can reuse this cookie for scripted requests during development.
curl -c cookies.txt -X POST https://api.tigertrust.example.com/api/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]", "password": "correct-horse-battery-staple"}'
# Reuse the cookie
curl -b cookies.txt https://api.tigertrust.example.com/api/auth/user
{
"data": {
"message": "Login successful",
"user": {
"id": "usr_7f2a",
"email": "[email protected]",
"firstName": "Alice",
"currentWorkspaceId": "ws_2p9x8f4"
}
}
}
Google OAuth
For interactive sign-in, direct the browser to the Google sign-in flow via the sign-in page. After authenticating with Google, TigerTrust sets a session cookie — this is not an OAuth 2.0 access token flow for third parties. Server-to-server callers should use API keys instead.
Workspace selection
Session-authenticated requests default to the user’s current workspace. To act against a different workspace, add:
X-Workspace-Id: <workspace-id>
API-key requests are scoped to the workspace the key was created in; the X-Workspace-Id header is not respected for API-key calls.
Authentication errors
Authentication failures return 401 Unauthorized:
{ "error": { "code": "UNAUTHORIZED", "message": "Unauthorized" } }
See also