Support actor_token in RFC 8693 token exchange

[jhrozek]

Summary

An agent calling the token-exchange grant could previously only be
identified by its own OAuth client credentials at the endpoint. RFC
8693 also defines an explicit actor_token: a second, self-issued JWT
the agent presents alongside the user's subject_token, letting the
exchange name a specific acting-agent identity distinct from the
authenticated OAuth client itself (RFC 8693 §2.1's actor-delegation
use case). The handler unconditionally rejected both actor_token and
actor_token_type before this change ("not yet supported").

What changed:

• Accept actor_token + actor_token_type instead of rejecting them
  outright. resolveActorIdentity validates actor_token against the
  server's own JWKS (self-issued only — an actor_token is never
  accepted from an external trusted issuer). The binding check requires
  the actor_token's own client_id claim to equal the authenticated
  client's ID (proving the token was minted for this client); its
  sub claim is returned as the asserted actor identity, which may
  name a specific agent instance or delegate persona distinct from the
  client's own ID.
• That asserted actor identity is used only for may_act.sub
  matching and the emitted act.sub claim. Every client-identity policy
  decision — the delegate-client allowlists (configuredDelegateClients,
  AllowedDelegateClients), and the subject token's own client_id
  binding — is bound to the authenticated OAuth client (client.GetID()),
  never to the asserted actor. Conflating the two would let a client
  exchange a subject token issued to a different client, simply by
  presenting an actor_token whose sub happens to equal that subject
  token's client_id claim — a full bypass of the "subject token was
  issued to a different client" check. A regression test
  (actor_token cannot bypass subject-token client_id binding) pins
  this.
• id_token remains rejected as a subject_token_type value: an ID
  token's claim conventions differ from an access token's (e.g. aud
  names the relying-party client, not a resource), and this validator
  applies neither a distinct validation profile nor id_token-specific
  claim mapping. Accepting the type without that profile would silently
  validate an ID token exactly like an access token, ignoring the
  declared type's semantics. The same reasoning excludes id_token for
  actor_token_type: an actor presents a bearer credential
  (access_token/jwt), not an identity assertion.
• Removed the now-superseded validateExchangeParams helper (the old,
  actor_token-rejecting parameter validator) in favor of the new
  validateFormParams/resolveActorIdentity split.
• Corrected docs/arch/token-delegation-act-chain.md, which still
  described RFC 8693's chained-act-claim nesting as "not implemented"
  — that landed separately in Add a consent model for external OIDC subject tokens #6149 before this branch was rebased;
  the doc had gone stale, not the behavior.
• Added integration/unit coverage for: actor_token composing
  correctly with the configured-delegate-client relaxation (a
  mismatched actor_token is still rejected during actor-identity
  resolution, before delegation consent is ever reached); the asserted
  actor flowing into act.sub while the issued token's own client_id
  still names the authenticated client; and the client_id-binding
  bypass regression above.

What this enables: a client can present a second, independently-issued
token that both proves it was minted for that client and names a more
specific actor (e.g. a particular agent instance) than the client's own
ID — without that asserted actor ever being able to influence which
subject tokens the client is allowed to exchange.

No new server configuration is introduced — actor_token/actor_token_type
are request-time form parameters at /oauth/token, not RunConfig/CRD
fields. Example request, assuming a confidential client already
registered for the token-exchange grant:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<user's JWT>
&subject_token_type=urn:ietf:params:oauth:token-type:jwt
&actor_token=<agent's own self-issued JWT, client_id=agent-client-id, sub=agent-instance-42>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&client_id=agent-client-id
&client_secret=...

The delegated access token's act claim carries the asserted actor
identity; its own client_id still names the authenticated client:

"act": { "sub": "agent-instance-42" },
"client_id": "agent-client-id"

Fixes #5815

Type of change

• New feature

Test plan

• Unit tests (task test)
• Linting (task lint-fix)

API Compatibility

• This PR does not break the v1beta1 API, OR the api-break-allowed label is applied and the migration guidance is described above.

Does this introduce a user-facing change?

Yes: clients performing RFC 8693 token exchange against the embedded
authorization server can now supply actor_token/actor_token_type
(previously always rejected) to assert a specific actor identity distinct
from their own client ID. id_token remains rejected as a
subject_token_type/actor_token_type value. No existing request shape
changes behavior.

[codecov]

Codecov Report

❌ Patch coverage is 97.05882% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.01%. Comparing base (8343851) to head (aec1464).

Files with missing lines	Patch %	Lines
pkg/authserver/server/tokenexchange/handler.go	96.96%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6331      +/-   ##
==========================================
+ Coverage   72.96%   73.01%   +0.04%     
==========================================
  Files         742      742              
  Lines       78236    78271      +35     
==========================================
+ Hits        57085    57146      +61     
+ Misses      17172    17130      -42     
- Partials     3979     3995      +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JAORMX]

Panel review against RFC 8693, RFC 8725, RFC 9700, OIDC Core errata set 2, and the current IANA OAuth registry. The ID-token validation issue is the merge blocker; the other comments are concrete conformance and repository-rule fixes.

[JAORMX]

The earlier ID-token validation, RFC 8693 invalid_request, terminology, and response-drain comments are addressed. One authorization blocker remains: the new distinct actor subject is being reused as the authenticated client identity for delegate policy and the emitted client_id; see the inline comment.

Before merge, please also rebase onto current main so #6333/#6334 release/workflow/chart changes disappear from this PR, and update the title/body: they still advertise id_token support, sub == client_id, and proof-of-possession behavior that the branch now intentionally removed.

[JAORMX]

Verified aec146474: the authenticated OAuth client now remains authoritative for configured/allowed delegate policy, subject-token client_id binding, and the issued RFC 9068 client_id; the asserted actor is limited to may_act.sub and act.sub. The new regression tests cover the original actor-sub collision bypass. The branch is rebased, unrelated release/workflow files are gone, and the title/body now match the implementation.

The remaining failing unit-test check is GitHub infrastructure: the job never reached checkout/tests because codeload repeatedly returned 429/503 while downloading actions. Security, lint, codegen, docs, Helm, and two lifecycle matrices pass; the third lifecycle matrix is still running.