[OPIK-7940] [BE] [FE] feat: dynamic token auth (OAuth2 client credentials) for custom AI providers - #7910
[OPIK-7940] [BE] [FE] feat: dynamic token auth (OAuth2 client credentials) for custom AI providers#7910miguelgrc wants to merge 7 commits into
Conversation
|
🔄 Test environment deployment process has started Phase 1: Deploying base version You can monitor the progress here. |
⏱️ pre-commit per-hook timing
⏭️ 39 skipped (no matching files changed)
|
|
This change looks worth a test. This adds an OAuth2 client-credentials auth mode to the custom-provider dialog (new Authentication card, credential rows, Check connection), a new POST /v1/private/llm-provider-key/auth-config/test, and a write-only SECRET round-trip on GET — and it moves the existing static API key field inside that new card. Nothing e2e asserts this dialog today: Would target What it would check
Deploying a test environment for this PR and exploring it — results will follow in a comment. also touches Backend (Java API / internal), Deployment / Helm Advisory, from the QA test radar. Nothing here blocks this PR, and anything it proposes is a draft for review. Re-checked after a push on 19 Aug 15:36 UTC. |
|
✅ Test environment is now available! To configure additional Environment variables for your environment, run [Deploy Opik AdHoc Environment workflow] (https://github.com/comet-ml/comet-deployment/actions/workflows/deploy_opik_adhoc_env.yaml) Access Information
The deployment has completed successfully and the version has been verified. |
|
🌙 Nightly cleanup: The test environment for this PR ( |
Details
Enterprise AI gateways commonly forbid static API keys and instead require short-lived bearer tokens minted via the OAuth2 client credentials grant. This PR adds a dynamic token auth mode to Custom AI providers (and Bedrock/Ollama-style custom endpoints): Opik fetches the token from the customer's auth service before LLM calls and manages its whole lifecycle, so online evaluations and the Playground work against these gateways with zero manual token handling.
auth_configrecipe (token URL, send mode, credentials, reply field paths, fallback TTL) stored AES-GCM-encrypted in one MySQL column. Secret values are write-only: read-back masks them with a__SECRET__sentinel, and whole-document updates resolve sentinels against the stored recipe.strictby default, withrelaxedshipped explicitly in the docker-compose and Helm distributions. OTel metrics cover token requests and fetch durations, labeled by outcome and origin (request vs test button).POST /v1/private/llm-provider-key/auth-config/testruns the fetch server-side (rate-limited, redacted errors) and the dialog surfaces the result with the token lifetime.client_id,client_secret, optional extras likescope);grant_type=client_credentialsis injected automatically. Stored secrets render write-only (no reveal, locked). The backend recipe stays fully general, so other flows can be surfaced later as UI-only changes.Change checklist
Issues
AI-WATERMARK
AI-WATERMARK: yes
Testing
Automated (all passing locally):
mvn teston the feature's classes — token fetcher/cache (16), intercepting HTTP client incl. streaming retry semantics (14), destination guard (19), provider key resource incl. auth-config CRUD, masking and check endpoint (13), recipe validation and encryption utils.mvn compile+spotless:checkclean after rebase on latestmain.npm run lint,npm run typecheck,npm run deps:validate, and 27 vitest cases over the form↔recipe converters (sentinel round-trip, clear-vs-omit semantics, grant_type injection/hiding).Manual, against a local stack with a mock OAuth2 token service + bearer-validating gateway (and separately a real JWT-issuing OAuth2 server):
Not run: full repository-wide BE test suite (targeted classes instead, per repo convention). Playwright e2e specs for these flows are ready as a follow-up stacked PR.
Documentation
N/A — a docs page (provider setup + API-driven rotation snippet) follows in the stacked e2e/docs PR.