feat(provider): support for SPIFFE backed token exchange

[grs]

Summary

This PR adds the ability to specify token_exchange instead of a simple token_grant in a provider profile, with the goal of automatically obtaining a token that combines the agents identity with that of the user on whose behalf it is acting.

As with the existing token grants, the token exchange is initiated by the supervisor proxy. In the case of an exchange however it requires a subject token that has the supervisor clients id in the audience. To get this, a two stage exchange is required.

The supervisor first requests a token from the gateway. The gateway does the first exchange, using the identified credential in a provider as the subject and requesting the audience needed for the supervisor (which is based on the supervisors SPIFFE ID). The token from that exchange is then returned to the supervisor which uses it as the subject for a further exchange. The resulting token than has the subject of the original provider credential but the sandbox (as identified by its SPIFFE ID) as the authorized party.

An option was also added to the CLI for provider create|update, allowing the current OIDC token to be stored.

Related Issue

Fixes #1987

Changes

• Added token_exchange as a provider token grant mode alongside client_credentials.
• Extended provider profiles/protobuf with subject-token metadata, requested token type, and SPIFFE JWT-SVID settings.
• Added gateway-side subject-token exchange support for sandbox-scoped dynamic credentials.
• Added shared SPIFFE/JWT-SVID helpers and gateway SPIFFE Workload API Helm wiring.
• Updated CLI option to store current OIDC token.

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)
• Manual tests of token exchange, including with updated token, as well as of the original simple token grant.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[grs]

@mrunalp @TaylorMutch just fyi, I have verified that this works with both currently supported supervisor topologies.

[afourniernv]

Context from the Okta side: I have a live-tested RFC 8693 OBO implementation in #1681. That path exchanges the logged-in user subject token at Okta using the Okta client ID/secret, audience, and scope.

Before I rework it around this PR: is #1970 intended to support that kind of Okta token endpoint/client-secret exchange, or does the new two-stage flow require the IdP to accept SPIFFE JWT-SVID client assertions?

If the latter, I will need to validate/configure that separately before wiring OBO into the NemoClaw reference.

[grs]

@afourniernv At present it does indeed require the IdP to accept SPIFFE JWT-SVIDs. That could certainly be expanded, but I do think that the intention for this path (i.e. the current dynamic token grant path) is for it to use some 'platform provided' credential that is (or can be) scoped to the sandbox.

If the user is providing a client secret for the exchange through a provider, then in my view the approach in your PR seems like the simplest/cleanest. In that case the gateway can handle it in much the same way as a token refresh (as your PR shows).

[grs]

/ok