For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Setting up JWT token authentication for programmatic and service access
JWT (JSON Web Token) authentication enables programmatic access to Opik using externally issued tokens. This is ideal for service-to-service authentication, custom auth flows, and integration with existing JWT-based systems.
JWT authentication is available on Enterprise plans. This feature is not available in open-source deployments. Reach out if you want to enable this feature for your Opik deployment.
When to use JWT authentication
JWT authentication is best suited for:
Backend services that need to access Opik’s API
CI/CD pipelines running automated experiments
Custom applications with existing JWT infrastructure
Service-to-service communication without user interaction
For human users logging in interactively, consider SAML or OIDC SSO instead.
Prerequisites
Before configuring JWT authentication, you need:
Organization admin access to Opik
Enterprise plan enabled for your organization
JWT infrastructure capable of issuing signed tokens
JWKS endpoint (recommended) or public key for token verification
If valid, the request is processed as the mapped user.
Configuration options
JWT authentication can be configured with either:
Option
Description
Use case
JWKS URI
URL to fetch public keys dynamically
Recommended for most deployments
Static Public Key
Fixed public key for verification
On-premises deployments only
You must configure either a JWKS URI or a static public key, but not both.
Configuring JWT authentication
Step 1: Navigate to SSO settings
Go to Admin Dashboard > SSO Configuration.
Select JWT Authentication (may be under advanced options).
Step 2: Choose key verification method
JWKS URI (Recommended)
Static Public Key (On-Prem Only)
Using JWKS URI
JWKS (JSON Web Key Set) is the recommended approach as it:
Supports automatic key rotation
Allows multiple keys for seamless rotation
Follows industry best practices
Configuration:
Field
Description
Example
JWKS URI
URL of your JWKS endpoint
https://auth.company.com/.well-known/jwks.json
Requirements:
The endpoint must be publicly accessible (or accessible from Opik’s servers).
Must return valid JWKS JSON format.
Must be unique across organizations (no two orgs can share a JWKS URI).
Should support HTTPS.
Example JWKS response:
1
{
2
"keys": [
3
{
4
"kty": "RSA",
5
"kid": "key-1",
6
"use": "sig",
7
"n": "0vx7agoebGcQ...",
8
"e": "AQAB"
9
}
10
]
11
}
Step 3: Configure subject mapping
Subject mapping determines how Opik identifies users from JWT claims:
Field
Description
Options
Subject Mapping Type
How to interpret the subject claim
EMAIL or USER_NAME
Subject Claim Name
Which claim contains the subject
Default: sub
Subject mapping types:
Type
Description
Example claim value
EMAIL
Subject is an email address
user@company.com
USER_NAME
Subject is a username
jsmith
Use EMAIL mapping when your JWT tokens contain email addresses in the subject claim. This is the most common configuration.
Custom claim name:
By default, Opik reads the sub (subject) claim. If your tokens use a different claim:
1
{
2
"sub": "12345",
3
"email": "user@company.com",
4
"preferred_username": "jsmith"
5
}
Set Subject Claim Name to email or preferred_username to use those claims instead.
Step 4: Configure optional restrictions
Allowed issuers
Restrict which token issuers are accepted:
Field
Description
Allowed Issuers
List of accepted iss claim values
Example:
https://auth.company.com
https://auth.partner.com
If configured, tokens with issuers not in this list will be rejected.
Allowed audiences
Restrict which audiences are accepted:
Field
Description
Allowed Audiences
List of accepted aud claim values
Example:
opik-api
https://api.opik.com
If configured, tokens without a matching audience claim will be rejected.
Security best practice: Configure both allowed issuers and audiences to ensure only specifically intended tokens can access your organization.
JWT token requirements
Required claims
Your JWT tokens must include:
Claim
Description
Example
sub (or custom)
Subject identifying the user
user@company.com
iat
Issued at timestamp
1704067200
exp
Expiration timestamp
1704070800
Recommended claims
Claim
Description
Example
iss
Token issuer
https://auth.company.com
aud
Intended audience
opik-api
Required header
When using JWKS with multiple keys:
Header
Description
Example
kid
Key ID matching JWKS key
key-1
alg
Algorithm (must match key)
RS256
Multi-tenant requirement: If your JWKS endpoint contains multiple keys, the JWT must include a kid (Key ID) header to identify which key to use for verification. Missing kid headers can cause authentication failures.
Using JWT authentication
API requests
Include the JWT in the Authorization header:
$
curl -X GET "https://api.opik.com/v1/projects" \
>
-H "Authorization: Bearer <your-jwt-token>"
SDK configuration
Configure the Opik SDK to use JWT authentication:
Python
TypeScript
1
import opik
2
3
# Configure with JWT token
4
client = opik.Opik(
5
api_key="<your-jwt-token>",
6
workspace="your-workspace"
7
)
Key caching and performance
JWKS caching
Opik caches JWKS responses to improve performance:
Cache duration: Keys are cached and periodically refreshed.
Automatic refresh: Keys are fetched on cache expiry or when a new kid is encountered.
Fallback: If JWKS endpoint is temporarily unavailable, cached keys are used.
Configuration options (on-premises)
On-premises deployments can configure caching behavior:
Environment variable
Description
Default
JWKS_CACHE_UPDATE_SECONDS
How often to refresh the cache
300 (5 minutes)
JWKS_FETCH_TIMEOUT_MS
Timeout for JWKS fetch requests
5000 (5 seconds)
Troubleshooting
Common issues
Issue
Possible cause
Solution
”Invalid token signature”
Key mismatch
Verify JWKS endpoint returns correct keys
”Token expired”
exp claim in the past
Issue tokens with appropriate expiration
”Unknown key ID”
kid not in JWKS
Ensure token kid matches a key in JWKS
”Invalid issuer”
iss not in allowed list
Add issuer to allowed issuers or remove restriction
”Invalid audience”
aud not in allowed list
Add audience to allowed audiences or remove restriction