RFC: OIDC federation — keyless CI auth for codex-lb

[DongwonTTuna]

English first, 한국어는 아래에.

TL;DR

I've been prototyping IdP-agnostic OIDC federation for codex-lb: a CI/CD job presents its short-lived OIDC ID token and gets back a short-lived sk-clb- key — no long-lived secret stored anywhere. Same model as AWS STS AssumeRoleWithWebIdentity / GCP Workload Identity Federation, opt-in and off by default. Before taking it further, I'd like a read on whether this direction is welcome and in scope — if so, I'll build it out on my side and open a PR.

The problem

Anything outside the dashboard — a GitHub Actions job, an agent, a CI pipeline — currently needs a long-lived sk-clb- key stored as a secret. A stored credential is a standing leak surface and a rotation chore. (cf. #280 — there's already appetite for safer secret handling.)

Proposal

I'd like to bring OIDC federation to codex-lb — the de-facto standard for keyless auth in the cloud world, and a clear security win. The idea: instead of storing a secret, a CI/CD job exchanges its built-in OIDC token for a short-lived sk-clb- key, minted on demand.

Why it helps

• Nothing to store — the secret that could leak simply doesn't exist anymore.
• Self-expiring — the key lives only as long as the job, so a leak is worthless minutes later.
• Auto-rotating — a fresh key every run; nothing to rotate by hand.
• Scoped — narrow each job to a repo, specific models, and usage limits.

How it works

It's how GitHub Actions already authenticates to AWS and GCP without storing any cloud keys. A CI runner carries a short-lived, signed token that proves "I'm this job, in this repo." codex-lb verifies that proof, checks it against a rule you set (e.g. repository = my-org/my-repo), and hands back an sk-clb- key that expires in minutes.

Under the hood

• OidcProvider (issuer + audience + JWKS) → OidcBinding (claim conditions like repository = org/repo + a minted-key template).
• POST /v1/oidc/token: verifies the JWT, matches a binding, then mints a short-lived sk-clb- through the existing create_key — with TTL clamp, account scope, model enforcement, and budget/usage limits.
• IdP-agnostic (GitHub, GitLab, Google, Okta…); claim matching is data-driven — a new IdP is config, not code.
• Opt-in, off by default; reuses create_key/delete_key, so the credential authority is unchanged.

How it compares

Among tools that gate access to LLM / API keys:

	OIDC → short-lived key	Notes
codex-lb today	❌	static long-lived key in a CI secret (OSS & free, but no such feature)
LiteLLM	⚠️ partial	JWT maps to an existing key, not a fresh mint — and it's enterprise-only (paid)
This proposal	✅	true short-lived mint, STS-style — free & open-source

The token-exchange model itself is already industry-standard — AWS STS AssumeRoleWithWebIdentity, GCP Workload Identity Federation, and HashiCorp Vault all work this way. This just brings it to codex-lb, free and open.

The ask

1. Is OIDC federation something you'd want upstream?
2. Any scope or design constraints I should respect — endpoint path, settings naming, where the module should live?

If the direction's welcome, I'll build it out and open a PR.

---

한국어

요약

codex-lb에 IdP에 종속되지 않는 OIDC 페더레이션을 붙여보고 있습니다. CI/CD 작업이 실행할 때마다 발급받는 수명이 짧은 OIDC ID 토큰을 제시하면, 마찬가지로 수명이 짧은 sk-clb- 키를 돌려받는 방식이라, 오래 보관해야 하는 시크릿이 어디에도 남지 않습니다. AWS STS AssumeRoleWithWebIdentity나 GCP Workload Identity Federation과 동일한 모델이고, 기본값은 꺼져 있어 원하는 사람만 켜서 쓰면 됩니다. 더 진행하기 전에 이 방향을 upstream에서 받아주실 만한지, 그리고 프로젝트 범위에 맞는지 먼저 여쭙고 싶습니다. 괜찮다면 제 쪽에서 구현해서 PR로 올리겠습니다.

문제

지금은 대시보드 바깥에서 동작하는 모든 워크로드(GitHub Actions, 에이전트, CI 파이프라인 등)가 수명이 긴 sk-clb- 키를 시크릿으로 저장해 둬야 합니다. 한번 저장된 자격증명은 그 자체로 상시 유출 위험이고, 주기적으로 교체해 줘야 하는 부담도 따릅니다. (참고로 #280처럼, 시크릿을 더 안전하게 다루고 싶다는 요구가 이미 있습니다.)

제안

클라우드 업계에서 키리스(keyless) 인증의 사실상 표준이 되었고 보안 면에서도 분명히 앞서는 OIDC 페더레이션을 codex-lb에도 도입하고 싶습니다. 핵심은 이렇습니다. 시크릿을 저장해 두는 대신, CI/CD 작업이 자신의 OIDC 토큰을 그때그때 수명이 짧은 sk-clb- 키와 맞바꿔 쓰는 것이죠.

어떤 점이 좋아지나요

• 저장할 비밀이 없습니다 — 새어 나갈 시크릿 자체가 사라집니다.
• 알아서 만료됩니다 — 키가 작업이 도는 동안만 살아 있어서, 유출돼도 몇 분 뒤면 쓸모가 없습니다.
• 자동으로 갱신됩니다 — 실행할 때마다 새 키라, 사람이 손으로 교체할 게 없습니다.
• 범위를 좁힐 수 있습니다 — 작업마다 특정 저장소·허용 모델·사용 한도로 권한을 묶어 둡니다.

어떻게 동작하나요

GitHub Actions가 클라우드 키를 어디에도 저장하지 않고 AWS·GCP에 접속할 때 이미 쓰고 있는 바로 그 방식입니다. CI 러너는 실행될 때마다 "나는 이 저장소의 이 작업이다" 를 증명하는, 수명이 짧은 서명된 토큰을 자동으로 들고 있습니다. codex-lb 쪽에서는 그 증명을 검증하고, 미리 정해 둔 규칙(예: repository = my-org/my-repo)에 맞는지 확인한 뒤, 몇 분이면 만료되는 sk-clb- 키를 내어줍니다.

내부 동작

• 신뢰는 두 단계로 정의합니다. OidcProvider(issuer + audience + JWKS) → OidcBinding(repository = org/repo 같은 claim 조건 + 발급할 키의 템플릿).
• POST /v1/oidc/token: JWT를 검증하고, 조건에 맞는 binding을 찾은 뒤, 기존 create_key를 그대로 거쳐 수명이 짧은 sk-clb- 키를 발급합니다. 이때 TTL 상한, 계정 스코프, 허용 모델 제한, budget/usage 한도가 함께 적용됩니다.
• IdP에 종속되지 않습니다(GitHub, GitLab, Google, Okta 등). claim 매칭이 데이터 기반이라, 새 IdP를 추가할 때 코드가 아니라 설정만 바꾸면 됩니다.
• 기본적으로 꺼져 있어 켜야만 동작합니다. 키 발급·삭제는 기존 create_key/delete_key를 그대로 재사용하므로, 키를 만들고 지우는 핵심 경로에는 손대지 않습니다.

비교

LLM·API 키 접근을 통제하는 도구들과 비교하면:

	OIDC → 단기 키 발급	비고
codex-lb (현재)	❌	CI 시크릿에 장기 키 저장 (오픈소스·무료지만 이 기능 자체가 없음)
LiteLLM	⚠️ 부분적	JWT를 기존 키에 매핑할 뿐 새 키 발급은 아님. 게다가 enterprise 전용(유료)
이 제안	✅	STS 방식의 진짜 단기 키 발급. 무료·오픈소스

토큰 교환 방식 자체는 이미 업계 표준입니다. AWS STS AssumeRoleWithWebIdentity, GCP Workload Identity Federation, HashiCorp Vault가 모두 이 방식으로 동작합니다. 이걸 codex-lb에 무료·오픈소스로 들여오는 것입니다.

요청

1. OIDC 페더레이션을 upstream에 들이실 의향이 있으신가요?
2. PR을 올리기 전에 제가 맞춰야 할 범위나 설계상의 제약이 있을까요? (엔드포인트 경로, 설정 이름, 모듈 위치 등)

방향만 괜찮다고 해주시면, 구현해서 PR로 올리겠습니다.