JWT Authentication
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
- Client sends an API request with a JWT in the
Authorizationheader. - Opik fetches public keys from your JWKS endpoint (cached for performance).
- Opik verifies the JWT signature using the appropriate key.
- Opik validates claims (issuer, audience, subject).
- If valid, the request is processed as the mapped user.
Configuration options
JWT authentication can be configured with either:
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:
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:
Step 3: Configure subject mapping
Subject mapping determines how Opik identifies users from JWT claims:
Subject mapping types:
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:
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:
Example:
If configured, tokens with issuers not in this list will be rejected.
Allowed audiences
Restrict which audiences are accepted:
Example:
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:
Recommended claims
Required header
When using JWKS with multiple keys:
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:
SDK configuration
Configure the Opik SDK to use JWT authentication:
Python
TypeScript
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
kidis encountered. - Fallback: If JWKS endpoint is temporarily unavailable, cached keys are used.
Configuration options (on-premises)
On-premises deployments can configure caching behavior:
Troubleshooting
Common issues
Debugging JWT tokens
Decode and inspect your JWT token (do not use for production tokens containing secrets):
Or use jwt.io to inspect token contents.
Verifying JWKS endpoint
Test that your JWKS endpoint is accessible and returns valid JSON:
Verify that:
- The endpoint returns HTTP 200.
- Response is valid JSON with a
keysarray. - Keys include
kid,kty, and algorithm-specific fields.
Token generation checklist
Before integrating, verify your tokens:
- Signature: Token is signed with a key in your JWKS.
- Header: Includes
kidmatching a key in JWKS (if multiple keys). - Subject: Contains user email or username in the configured claim.
- Expiration:
expclaim is in the future. - Issuer: Matches allowed issuers (if configured).
- 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
- Configure SAML for interactive user authentication.
- Configure OIDC for OAuth-based authentication.
- Create service accounts for an alternative programmatic access method.