feat(auth): add X.509 workload token exchange - #935
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Castiron custom codeMixed files: 53 → 63 10 newly customized · 0 customizations removed · 2 existing customizations changed · 0 generated baselines changed Compared
51 existing customizations unchanged
11 more in the full report. A changed generated baseline means this report cannot reliably identify which handwritten lines changed. Inspect the custom-code diffDownload the exact patch produced by this run (requires repository access): gh run download 32925449168 --repo openai/openai-java \
--name castiron-custom-code-32925449168-1 --dir /tmp/castiron-custom-code-32925449168-1
git apply --stat /tmp/castiron-custom-code-32925449168-1/custom-code.patch
cat /tmp/castiron-custom-code-32925449168-1/custom-code.patchOr reproduce it from an SDK checkout containing the vendored reporter: git fetch --no-tags origin 23038252822fb2b68e61ba230a8349869e1455d5 57b21307aea15900f5d10fd76b233f52f3b488fa
python3 scripts/castiron/custom_code_report.py report \
--base 23038252822fb2b68e61ba230a8349869e1455d5 \
--head 57b21307aea15900f5d10fd76b233f52f3b488fa --fetch --require-head-hash --public \
--out /tmp/castiron-custom-code-57b21307aea1
cat /tmp/castiron-custom-code-57b21307aea1/custom-code.patchThis is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01e93c7cc8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
HAYDEN-OAI
left a comment
There was a problem hiding this comment.
Reviewed the exact stacked token-exchange diff. Found an additional P1: transient issuer-response body failures are misclassified as permanent malformed-data errors. The existing unresolved credential-bearing response-header finding also remains substantive, so this revision should not be approved yet.
51351c5 to
04e7cf8
Compare
## Summary - add public sync and async `x509Builder` entry points backed only by caller-attested `X509Transport` - bind isolated exchange and API clients while preserving exact ownership and close behavior - enforce fixed X.509 issuer/API origins, bearer-only route eligibility, and exclusive authentication/provider configuration - validate the final request boundary before exchanging or dispatching credentials - use OkHttp call lifecycle events so client close cancels exchange/API calls through response-body completion ## Security and ownership boundaries - API origin is fixed to `https://mtls.api.openai.com/v1`; the exchange origin remains `https://mtls.auth.openai.com/oauth/token` - no custom base URL, data residency, Azure/Bedrock/provider auth, proxy, arbitrary transport, or organization/project routing can be combined with X.509 mode - user-supplied authorization, API-key, proxy-auth, cookie, host/authority, organization, and project headers are rejected at the final sink - the authenticator owns only the exchange client; `ClientOptions` owns the real API client - no token caching, shared retry budget, 401 rotation, or long-lived lifecycle policy in this slice ## Validation - real loopback CONNECT plus mTLS sync/async Files API coverage verifies SNI, certificate chain, exact exchange body, bearer placement, and header separation - focused construction, Java-visibility, exclusivity, cloning, build isolation, cancellation, blocked exchange/API close, stalled response-body close, and retry-after-close tests - repository lint: passed - repository scripts/build: passed - full Gradle test graph through scripts/test: BUILD SUCCESSFUL, including R8 and ProGuard; the wrapper cleanup trap subsequently observed its mock-server PID had already exited - Castiron custom-code budget: 1610 of 2000 lines, unchanged, 390 lines headroom - two independent review cycles completed and remediated; final Reviewer A and Validator B passes clean - mandatory thermo-nuclear quality review completed, remediated, and rerun clean ## Stack 1. #929 — executable raw-wire oracle (merged) 2. #934 — fixed-alias direct mTLS transport capability 3. #935 — identity metadata and exact token exchange 4. this PR — minimal sync/async client integration with fixed origins and exclusive auth 5. planned — lifecycle, cache, single-flight, retry/deadline, 401 rotation, installed-JAR docs, and protected live E2E Stacked on #935.
## Summary - introduce a single retry/authentication orchestrator for X.509 requests while preserving the ordinary-client retry path unchanged - cache exchanged bearer tokens with expiry skew, single-flight refresh, rejected-generation invalidation, and one bounded 401 replay - propagate request deadlines, cancellation, stream close, and client close through authentication, backoff, transport calls, request bodies, responses, parsing, and logging - preserve exact client/pipeline ownership across sync/async views, reusable builders, generated `Unit` endpoints, and raw-response continuations - add installed-JAR documentation, a runnable example/runtime probe, and a protected opt-in live X.509 smoke workflow ## Compatibility and security boundaries - ordinary non-X.509 construction and retry/completion behavior remains on the pre-existing code path - X.509 remains fixed to the attested transport and fixed auth/API origins introduced by the earlier stack layers - credentials remain bearer-only at the API boundary and are never added to logs, fixtures, examples, or default test output - cleanup helpers act only on internal pipeline-owned markers; ordinary raw-response ownership remains unchanged - public/source compatibility was verified against both baseline and proposed API manifests ## Validation - focused sync/async X.509 lifecycle matrix: passed, including token races, cancellation, deadlines, retries, 401 replay, builder/view ownership, request/response cleanup, logging, parsing, streams, and ordinary-client regressions - repository lint: passed - full `scripts/test` graph with Steady: passed, including R8 and ProGuard artifacts - Java 21 runtime compatibility probe: passed for core, OkHttp, Bedrock, and runtime providers - API/source breaking-change detector: passed for baseline and proposed public APIs - staged secret-pattern scan and `git diff --check`: passed - Castiron custom-code budget: 1668 of 2000 lines, 332 lines headroom; ratchet unchanged - first review cycle: two independent agents clean after all findings were fixed; mandatory thermo-nuclear review clean - second clean-room review cycle: two fresh independent agents clean on the exact frozen 49-file diff (`1e5bba26e91a638915bfa509e87adee10b598c5d92bd23ae54a98a504a4e9fe6`) ## Stack 1. #929 — executable raw-wire oracle (merged) 2. #934 — fixed-alias direct mTLS transport capability 3. #935 — identity metadata and exact token exchange 4. #936 — minimal sync/async client integration with fixed origins and exclusive auth 5. this PR — lifecycle, cache/single-flight, 401 rotation, deadline/cancellation ownership, installed-JAR docs, and protected live E2E Stacked on #936.
HAYDEN-OAI
left a comment
There was a problem hiding this comment.
Reviewed the current X.509 integration and verified the earlier issuer-header, async-handle, and retryable-I/O findings were fixed. One new P1 remains: blocking issuer-body parsing can exhaust the JVM common pool and prevent async request deadlines from ever starting.
| val responseFuture = httpClient.executeAsync(request(), requestOptions) | ||
| val result = CompletableFuture<X509AccessToken>() | ||
| val activeResponse = AtomicReference<ResponseLease?>() | ||
| responseFuture.whenCompleteAsync { response, error -> |
There was a problem hiding this comment.
[P1] Keep blocking issuer-body parsing off the JVM common pool. whenCompleteAsync without an executor runs parse(response) and its blocking readTree(response.body()) on ForkJoinPool.commonPool(). With concurrent X.509 clients and issuer responses whose headers arrive while their bodies stall, each exchange occupies a common-pool worker until its read timeout (10 minutes by default, potentially unlimited). Once those workers are exhausted, public async requests cannot run their CancellationPropagatingFuture.thenComposeAsync dispatch callbacks, so they never enter the orchestrator to start their own request-deadline timers and can wait far beyond the caller's timeout; unrelated common-pool work is starved too. Move blocking issuer-response parsing to an appropriately owned I/O executor while preserving the existing cancellation and response-closing behavior.
Summary
Protocol boundaries
Validation
Stack
Stacked on #934.