JWT Authentication

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

How JWT authentication works

ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā” ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā” ā”Œā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”
│ Service/ │ │ Opik │ │ JWKS │
│ Client │ │ API │ │ Endpoint │
ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”¬ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜ ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”¬ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜ ā””ā”€ā”€ā”€ā”€ā”€ā”€ā”¬ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”˜
│ │ │
│ 1. Request with │ │
│ JWT in header │ │
│────────────────────>│ │
│ │ 2. Fetch keys │
│ │ (cached) │
│ │────────────────────>│
│ │<────────────────────│
│ │ │
│ │ 3. Verify JWT │
│ │ signature │
│ │ │
│ │ 4. Validate claims │
│ │ (iss, aud, sub) │
│ │ │
│ 5. API response │ │
│<────────────────────│ │
  1. Client sends an API request with a JWT in the Authorization header.
  2. Opik fetches public keys from your JWKS endpoint (cached for performance).
  3. Opik verifies the JWT signature using the appropriate key.
  4. Opik validates claims (issuer, audience, subject).
  5. If valid, the request is processed as the mapped user.

Configuration options

JWT authentication can be configured with either:

OptionDescriptionUse case
JWKS URIURL to fetch public keys dynamicallyRecommended for most deployments
Static Public KeyFixed public key for verificationOn-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

  1. Go to Admin Dashboard > SSO Configuration.
  2. Select JWT Authentication (may be under advanced options).

Step 2: Choose key verification method

Step 3: Configure subject mapping

Subject mapping determines how Opik identifies users from JWT claims:

FieldDescriptionOptions
Subject Mapping TypeHow to interpret the subject claimEMAIL or USER_NAME
Subject Claim NameWhich claim contains the subjectDefault: sub

Subject mapping types:

TypeDescriptionExample claim value
EMAILSubject is an email addressuser@company.com
USER_NAMESubject is a usernamejsmith

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:

FieldDescription
Allowed IssuersList 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:

FieldDescription
Allowed AudiencesList 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:

ClaimDescriptionExample
sub (or custom)Subject identifying the useruser@company.com
iatIssued at timestamp1704067200
expExpiration timestamp1704070800
ClaimDescriptionExample
issToken issuerhttps://auth.company.com
audIntended audienceopik-api

Required header

When using JWKS with multiple keys:

HeaderDescriptionExample
kidKey ID matching JWKS keykey-1
algAlgorithm (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:

1import opik
2
3# Configure with JWT token
4client = 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 variableDescriptionDefault
JWKS_CACHE_UPDATE_SECONDSHow often to refresh the cache300 (5 minutes)
JWKS_FETCH_TIMEOUT_MSTimeout for JWKS fetch requests5000 (5 seconds)

Troubleshooting

Common issues

IssuePossible causeSolution
ā€Invalid token signatureā€Key mismatchVerify JWKS endpoint returns correct keys
ā€Token expiredā€exp claim in the pastIssue tokens with appropriate expiration
ā€Unknown key IDā€kid not in JWKSEnsure token kid matches a key in JWKS
ā€Invalid issuerā€iss not in allowed listAdd issuer to allowed issuers or remove restriction
ā€Invalid audienceā€aud not in allowed listAdd audience to allowed audiences or remove restriction
ā€User not foundā€Subject doesn’t map to userVerify subject claim contains valid email/username

Debugging JWT tokens

Decode and inspect your JWT token (do not use for production tokens containing secrets):

$# Decode JWT header and payload (without verification)
$echo "<your-jwt>" | cut -d'.' -f1 | base64 -d 2>/dev/null | jq .
$echo "<your-jwt>" | cut -d'.' -f2 | base64 -d 2>/dev/null | jq .

Or use jwt.io to inspect token contents.

Verifying JWKS endpoint

Test that your JWKS endpoint is accessible and returns valid JSON:

$curl -s "https://auth.company.com/.well-known/jwks.json" | jq .

Verify that:

  • The endpoint returns HTTP 200.
  • Response is valid JSON with a keys array.
  • Keys include kid, kty, and algorithm-specific fields.

Token generation checklist

Before integrating, verify your tokens:

  1. Signature: Token is signed with a key in your JWKS.
  2. Header: Includes kid matching a key in JWKS (if multiple keys).
  3. Subject: Contains user email or username in the configured claim.
  4. Expiration: exp claim is in the future.
  5. Issuer: Matches allowed issuers (if configured).
  6. Audience: Matches allowed audiences (if configured).

Security best practices

Token lifecycle

  • Short expiration: Use short-lived tokens (e.g., 1 hour).
  • Refresh tokens: Implement token refresh for long-running processes.
  • Revocation: Have a process to rotate keys if compromised.

Key management

  • Key rotation: Rotate keys periodically (e.g., every 90 days).
  • Multiple keys: Maintain multiple keys in JWKS during rotation.
  • Secure storage: Protect private keys used for signing.

Access restrictions

  • Limit issuers: Configure allowed issuers to prevent token from unauthorized sources.
  • Limit audiences: Configure allowed audiences to ensure tokens are intended for Opik.
  • Monitor usage: Review authentication logs for anomalies.

Next steps