Cofide Credex

Modern systems rarely live within a single identity domain. SPIFFE workloads, cloud provider OIDC tokens, OAuth-protected APIs, and agentic AI pipelines all use different credential languages. Moving identity across these boundaries today typically means building bespoke adapters, issuing long-lived shared secrets, or accepting a gap in your audit trail.

Cofide Credex is an OAuth Authorization Server (AS) and Security Token Service (STS) that acts as a trust bridge. It lets workloads exchange credentials across identity protocols without static secrets or custom glue code, using standards that already exist.

Key capabilities

• RFC 8693 OAuth 2.0 token exchange - full support for both impersonation and delegation semantics
• SPIFFE-native client authentication (draft-ietf-oauth-spiffe-client-auth) - workloads authenticate with their JWT-SVID; no per-client secret registration needed
• Delegation-preserving chains - issued tokens carry both the subject (sub) and actor (act) identities, so every hop in a call chain is visible in the audit log
• Configurable policy - control which exchanges are permitted and what scopes can be granted using exchange policies registered in Connect
• Cross-domain bridges - connect SPIFFE trust domains to external OAuth-protected services, including legacy systems
• Exchange auditing - every token exchange is logged with full context, giving you a complete record of who requested what and on whose behalf

How token exchange works

RFC 8693 OAuth 2.0 Token Exchange defines a grant type where a client presents one or two existing tokens to a Security Token Service and receives a new token in return. The client’s own identity is asserted separately via client authentication, which in Credex means a SPIFFE JWT-SVID rather than a shared secret.

The two key inputs are the subject_token (the identity being delegated, e.g. the user’s access token) and the optional actor_token (the identity of the service performing the action, e.g. the workload’s JWT-SVID). Credex evaluates both against its delegation policy and mints a new token. In delegation mode that token carries both a sub claim (the original subject) and an act claim (the actor), so every downstream service can see the full picture.

flowchart LR
    ST["subject_token"]
    AT["actor_token"]
    CA["client_assertion"]
    STS(["Cofide Credex"])
    Policy{{"*Exchange Policy* from Cofide Connect"}}
    Issued["Issued Token (sub + act + scope)"]

    ST -->|subject| STS
    AT -->|actor| STS
    CA -->|client auth| STS
    STS -->|*evaluates*| Policy
    STS -->|*mints*| Issued

    classDef inputToken fill:#fcfcfc,stroke:#1c1d22,color:#1c1d22
    classDef outputToken fill:#fcfcfc,stroke:#1c1d22,color:#1c1d22
    classDef policyNode fill:#00d690,stroke:#1c1d22,color:#1c1d22
    classDef stsNode fill:#00d690,stroke:#1c1d22,color:#1c1d22

    class ST,AT,CA inputToken
    class STS stsNode
    class Policy policyNode
    class Issued outputToken

Agentic AI

The primary use case driving Credex is agentic AI. When a user authorizes an action, that authorization needs to travel intact through every layer of a multi-hop pipeline: from the web app to the orchestrating agent, from the agent to the MCP server, and from the MCP server to the external API it calls on the user’s behalf. With Credex, every token in that chain carries both who authorized the action and who is currently performing it. You get full delegation visibility without needing to embed credentials in prompts or rely on ambient service accounts.

Status

Cofide Credex is currently in feature preview and is under active development.

If you are building agentic AI systems or working on cross-domain workload identity and want to know more, get in touch.