Credex Use Cases

The following examples describe how Credex can be used to improve the security posture of real workloads.

Agentic AI delegation

In an agentic AI deployment, an end-user authorizes an action in a web app, which triggers an agent, which calls one or more MCP servers, which call external APIs on the user’s behalf.

Without token exchange, this pattern usually collapses to either embedding the user’s credentials in prompts or running every downstream call under an ambient service account that is indistinguishable from a system action. Neither preserves who authorized the action by the time it reaches the API.

Chained Exchanges using Credex

A token issued by Credex can itself be presented as the subject_token to a subsequent exchange, either against the same Credex deployment or against a downstream OAuth AS that trusts Credex as an issuer.

With Credex configured between each hop, the user’s identity is preserved in the sub claim throughout the chain, while every workload that touched the request appears in the nested act claim. Logs at the API show that the user authorized the action and which workloads acted on their behalf, without any of those workloads ever needing to hold the user’s credentials.

This is how a multi-hop pipeline carries the same principal across several boundaries. Each hop is a separate exchange, each governed by its own policy, and each can narrow the scopes granted on the next hop.

The end-to-end identity information flow in this scenario is:

sequenceDiagram
    participant U as User / Upstream IdP
    participant A as Agent
    participant M as MCP server
    participant API as External API
    participant C as Credex

    U->>A: user access token (subject)
    note over A,C: Agent exchanges user token with own JWT-SVID as actor
    A->>C: POST /token (subject_token=user_token, actor_token=agent JWT-SVID)
    C-->>A: access_token { sub: user, act: agent }
    A->>M: Bearer access_token
    note over M,C: MCP server exchanges received token with own JWT-SVID as actor
    M->>C: POST /token (subject_token=received token, actor_token=MCP JWT-SVID)
    C-->>M: access_token { sub: user, act: { sub: MCP, act: agent } }
    M->>API: Bearer access_token
    API->>API: sub = user, full act chain visible

Chained exchange relies on the access token being verifiable: each hop’s intermediate token is verified against Credex’s JWKS, so that the inbound subject token is validated before evaluating its policy.

Bridging SPIFFE with OAuth

Another scenario in which Credex can improve security posture is one in which a SPIFFE workload needs to call a downstream service that does not speak SPIFFE: it expects an OAuth bearer token whose aud matches its own identity.

The workload can use its JWT-SVID as a client assertion against Credex, requesting an access token with the downstream service as the token audience. If the exchange is allowed by Credex policy, then the workload can present the resulting token over HTTPS to the downstream service, which verifies the token against Credex’s /keys endpoint, just as it would for any other OAuth AS.

This pattern lets SPIFFE-attested workloads call legacy services without provisioning per-workload secrets and without the legacy service needing to learn anything about SPIFFE.

Federating to a legacy OAuth authorization server

Sometimes a workload needs to call a service that trusts its own OAuth authorization server, not Credex. The service will only accept tokens minted by that authorization server, so a SPIFFE SVID or Credex access token cannot be used on its own.

Unlike Credex, legacy OAuth authorization servers typically do not support using workload identity for client authentication. Rather than provisioning the workload with a long-lived client credential for the OAuth authorization server, Credex can bridge the exchange. The workload presents its own identity to Credex as usual, and Credex obtains a token from the downstream authorization server and returns it to the workload unchanged.

This is based on the “Authorization Server Acting as Client” pattern (Appendix B.2) of the IETF OAuth Identity and Authorization Chaining Across Domains draft, adapted as described under OAuth Bridge exchange on the Exchange Types page.

This lets a workload obtain a token from an external authorization server while its only durable credential remains its own identity. The workload never holds a client credential for the authorization server, so there is nothing to store, mount, or rotate, and the authorization server never needs to learn anything about SPIFFE.

That identity does not have to be a SPIFFE SVID. A workload can equally present an external JWT or OIDC ID token from a trusted issuer, so workloads running outside a SPIFFE trust domain can use the bridge too.

sequenceDiagram
    participant W as Workload
    participant C as Credex
    participant D as External OAuth AS
    participant S as External service

    W->>C: Present workload identity
    C->>D: Obtain token on the workload's behalf
    D-->>C: Access token
    C-->>W: Access token
    W->>S: Call with access token

See OAuth Bridge exchange on the Exchange Types page for the request and flow, and OAuth Bridge exchange on the Exchange Policies page for how to configure it.

Bridging OIDC with SPIFFE (Preview)

A third scenario involves a serverless workload running on AWS, GCP, or Azure which receives an ID token from the cloud provider’s local metadata service. By configuring the cloud provider as a trusted issuer, Credex will accept that token as a subject token and issue a JWT-SVID bound to a Cofide SPIFFE identity. This pattern allows workloads running in environments without a SPIRE agent to nonetheless obtain SPIFFE identities.

The reverse direction (presenting a SPIFFE JWT-SVID to obtain a cloud provider token) is handled outside Credex via standard OIDC federation: see External trust for the established trust setup.