ZTS Token Exchange: include SPIFFE ID claim in issued ID Token (JWT SVID support)

[ctyano]

Description

Today, ZTS supports OAuth 2.0 Token Exchange for issuing an OIDC-style id_token. It would be very useful if the id_token returned by ZTS could include a SPIFFE ID (e.g., spiffe://...) so that the exchanged ID Token can be directly used as a JWT SVID credential by workloads.

I'm aware Athenz can already issue JWT SVIDs via the Copper/Argos procedure, but Token Exchange is increasingly the common integration point for external identity providers and workload identity flows, and having ZTS return a JWT SVID-compatible ID Token would reduce operational complexity (fewer moving parts, simpler client bootstrap, and a single standardized exchange endpoint).

Background / motivation

We have services that already perform OAuth Token Exchange to obtain an ID Token for downstream authn/authz. If ZTS includes the SPIFFE ID in that issued ID Token, those services can reuse the same token as a JWT SVID for SPIFFE-aware systems, improving interoperability while keeping the identity anchored to ZTS-issued policy decisions.

Request

• For Token Exchange requests that result in issued_token_type=urn:ietf:params:oauth:token-type:id_token, include a SPIFFE ID claim in the returned ID Token when it can be derived from the subject token (or otherwise reliably determined).
• Clarify the claim name/format in docs (e.g., spiffe claim with spiffe://... URI).

Acceptance criteria

• When exchanging into an ID Token, the response id_token contains a SPIFFE ID claim (when available).
• Unit/integration tests cover presence/absence cases and validate no behavior regression.

Proposed contribution

If this approach is acceptable, I can open a PR implementing the claim propagation + tests + documentation updates.

[havetisyan]

The approach is fine. However, ZTS does not generate any spiffe uri values - it only has the validators to validate them. So in this mode, do we expect that the client would provide the spiffe value or what? if the spiffe value contains the namespace component - e.g. spiffe://<trust-doman>/ns/<namespace>/sa/<service-identity> then how would server know what is the namespace value?

[ctyano]

Thanks for the review. I think we can address it cleanly with an enhancement PR that binds the source credential's identifier (the authenticated Principal name) to the Principal name in the SPIFFE ID of the exchanged token, at the Authority class where we validate the Token Exchange subject token.

ZTS will continue to not invent a SPIFFE URI. The only behavior is propagation when the source credential already carries a Athenz Principal identifier (either as a dedicated claim or as sub in Athenz Principal form).
When the Authority accepts the source credential for Token Exchange, it will attest that the authenticated caller Principal and the subject-token identity are the same Athenz service identity:

• same Athenz domain
• same Athenz service (principal name)
• otherwise reject the exchange (it does not support client-supplied SPIFFE ID).

If the SPIFFE ID includes .../ns/<namespace>/... , the server can parse from the presented SPIFFE URI and use it only as an input to validation, and validate that the SPIFFE URI is internally consistent with the authenticated Athenz principal (domain/service).