Federated workload credentials
A workload can use a short-lived signed assertion from a trusted issuer to act as one confidential client in your organization.
Configure a rule
On OAuth Management, Clients, open the confidential client's row menu and choose Federated workload credentials. Add its HTTPS issuer and a JWKS address on that issuer's public host, the exact audience and subject, and up to five exact string claim conditions. Choose ES256 or RS256, an assertion lifetime from 60 to 600 seconds and clock skew from 0 to 60 seconds. The rule is stored only in this organization.
The registered assertion also authenticates this client is off by default. With it off, the client must additionally use its normal registered secret, key or certificate authentication. With it on, a job sends its client_id and matching signed assertion without storing that additional credential. This choice applies only to external JWT token exchange. Other grants keep their normal authentication. A supplied but invalid normal credential never falls back to assertion authentication.
Enable token exchange in Flow Policy and on the client. Its assigned scopes, resources, token manager and sender constraints still apply. Managing rules requires the separate federated-credential management permission. BTL organization administrators use the same controls under their current organization permissions. Public and built-in clients cannot receive these rules; dynamic registration cannot create them.
Exchange an assertion
POST to the organization's token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, subject_token_type=urn:ietf:params:oauth:token-type:jwt, the signed subject_token, client_id, and the intended scope and resource. The assertion must include iss, sub, aud, iat, exp and a unique jti. Actor tokens, ID-token scopes and refresh-token scopes are refused in this workload path.
The access token names this client as its subject. It cannot create a user, link accounts or sign anyone in. It never outlives the assertion. btl_workload_token_exchange_supported is a BTL discovery extension indicating that the tenant flow supports this path; it does not grant a client trust or advertise a dynamically registrable authentication method.
Each assertion works once. Optionally send a UUID workload_exchange_id and retain it privately with the exact request. If a response is lost, repeat that same request with the same ID and authentication mode. The service can return only its original still-active token with its remaining lifetime. A changed request, another client, an expired or revoked token, or a changed trust rule cannot recover it. Without an exchange ID, a replay is refused.
Lifetime, changes and history
Changing or deleting a trust rule ends the tokens it issued. Removing the client removes its active rules. Used assertion digests remain consumed through their expiry; a tenant restore carries that state and ends prior tokens rather than recovering old encrypted responses. Reset uses a new tenant generation.
Issuer keys are fetched over bounded HTTPS without redirects and cached. A key-source outage is unavailable, not proof that an assertion was invalid. Use the response's request ID to inspect authorized Audit and Logs. Records identify the action, client, rule and safe outcome without assertions, keys or claim values. The organization's Usage view shows issuer key fetches, active replay receipts and the largest credential count on one client. The per-client rule cap and shared replay capacity protect service storage.