bug: RBAC adapter makes distinct one-time public JWTs share an environment-key fingerprint #5080

Summary

At current main commit ba9448974f4b026efa62f2cb447c076d9a25b04f, authenticateRequestForApiBuilder() sets authentication.apiKey to result.environment.apiKey, including for an authenticated public JWT. The task trigger route then calls getOneTimeUseToken(authentication), which hashes authentication.apiKey.

Consequently, distinct one-time JWTs for the same environment produce the same one-time-use identifier: the environment key is hashed instead of the presented JWT. Once that identifier is present on a run, a fresh JWT can be rejected as already used.

Source path

1. Bearer resolver returns the authenticated environment plus oneTimeUse for a public JWT.
2. apiBuilder adapter places the environment key in authentication.apiKey.
3. One-time-use helper hashes that field.
4. Trigger route passes the resulting value to the run service. The engine converts a oneTimeUseToken uniqueness conflict to the already-used-token error.

Minimal illustration

This dependency-free example illustrates the collision; the source-extracted regression harness described below additionally executes the real functions.

const assert = require('node:assert/strict');
const { createHash } = require('node:crypto');
const environment = { apiKey: 'NONSECRET_OFFLINE_ENVIRONMENT_KEY' };

// Models the adapter after successful authentication of each distinct JWT.
function bridge(presentedJwt) {
  return { type: 'PUBLIC_JWT', oneTimeUse: true, apiKey: environment.apiKey };
}
function oneUseId(auth) {
  return createHash('sha256').update(auth.apiKey).digest('hex');
}

const jwtA = 'synthetic-distinct-jwt-a';
const jwtB = 'synthetic-distinct-jwt-b';
assert.notEqual(jwtA, jwtB);
// Fails: these must be distinct, but both hash the environment key.
assert.notEqual(oneUseId(bridge(jwtA)), oneUseId(bridge(jwtB)));

Source-extracted verification

Using Node 22.22.3 and TypeScript 5.9.3, an offline harness extracts the actual authenticateRequestForApiBuilder, getOneTimeUseToken and presentedBearerToken functions from that pinned commit and strips their types. Successful RBAC authentication is the fixture; the adapter and hashing functions are real upstream code. Two differently signed synthetic JWTs for one synthetic environment collide with the pristine adapter. No provider requests or real credentials are involved.

A proposed adapter correction passes eight checks: the baseline collision; distinct fresh-token fingerprints; identical-token replay identity; a minimal uniqueness model; non-one-time behavior; unchanged private-key behavior; forwarded RBAC denial; and fail-closed handling of an absent bearer token. The uniqueness model uses a Set, not the full run-engine database; full upstream integration testing remains necessary.

Suggested correction

Preserve the presented bearer JWT in authentication.apiKey for a successfully authenticated publicJWT subject, while leaving other subject types unchanged. The existing presentedBearerToken(request) helper can supply it after RBAC succeeds. Fail closed if that value is absent. Do not remove one-time protection or widen scopes.

const publicJwt = result.subject.type === "publicJWT"
  ? presentedBearerToken(request)
  : undefined;
if (result.subject.type === "publicJWT" && !publicJwt) {
  return { ok: false, status: 401, error: "Invalid or missing public JWT" };
}
// In the existing authentication object:
apiKey: publicJwt ?? result.environment.apiKey,

Alternatively, carry the presented-token identity in a dedicated field and hash that explicitly. The candidate has not been deployed, and all authentication paths need maintainer review before accepting it.

Hosted symptom and limits

A separate isolated Development check using SDK/CLI 4.8.1 and a verified V2 worker returned HTTP 422 with the one-time-token-used error on a fresh one-use token's only recorded caller submission. No new run appeared in the subsequent task/time-filtered read. Connection validation used a different read-only token. The caller stopped and did not retry.

This is consistent with the source defect, but we cannot attest which backend build processed that hosted request or its database state. We are not treating the local test as proof of a deployed fix. Related symptom report: #3780; a shared cause is not assumed.

Could you confirm whether the cloud task-trigger route uses this adapter and review the token identity passed to getOneTimeUseToken? The reproduction, regression tests and proposed patch are ready to share. No credentials, customer data, project IDs or run IDs are included here.