WIT: Your Identity Card

The Workload Identity Token (WIT) is a signed JWT issued by a trusted Identity Provider. It carries the workload's URI-based identity and a public key for proof-of-possession.

mTLS: Lock the Channel

Mutual TLS adds a transport-layer identity layer: both sides present X.509 certificates with SPIFFE URI Subject Alternative Names before any data flows.

WPT: Prove Each Request

A Workload Proof Token (WPT) is a short-lived, per-request JWT signed with the workload's private key. It binds to the WIT and to the exact target URI — making token theft useless.

The Validation Dance

When Workload B receives a request it runs 9 checks before letting it through. Each one protects against a specific attack class.

Fine-Grained Authorization

Authentication answers “who are you?” — Authorization answers “what are you allowed to do?” The WIT's sub and trust_domain drive fine-grained access control.

Selective Disclosure

An SD-WIT uses the SD-JWT standard to let a workload present only the claims a specific service needs — without re-issuance. Hidden claims are replaced with cryptographic hashes.

Token Exchange

Workload A (cloud-a.example) needs to call Workload B (cloud-b.example). Problem: B only trusts its own IdP. A Token Exchange Service bridges the trust domains.

Attacks & Defenses

What happens when an attacker captures a valid WPT and tries to replay it? WIMSE's jti tracking makes replay attacks impossible — even with a perfectly valid, unexpired stolen token.

OpenID Federation

Two organisations have their own IdPs and never exchanged a single key out-of-band. OpenID Federation 1.0 lets a shared Trust Anchor publish cryptographically-signed Subordinate Statements that vouch for each IdP, so any relying party can verify the chain at runtime.

Step 1 — Build the federation chain

Generate a Trust Anchor key pair, an IdP-B key pair, build a self-signed Entity Configuration for IdP-B, and have the Trust Anchor sign a Subordinate Statement certifying IdP-B's public key.

Step 2 — Verify the trust chain

The Resolver walks the chain: parse the EC to find authority_hints, fetch the Subordinate Statement from the Trust Anchor, verify the SS signature, extract IdP-B's key from the SS, verify the EC was signed by that key.

Step 3 — Federated exchange

A workload presents a WIT signed by IdP-B. The relying party has no static entry for IdP-B — it resolves the key dynamically via the federation resolver, then validates the WIT normally.

Transaction Tokens

A WIT answers "who is this workload?" — but in a microservice call chain, the receiving service also needs to know "why is this call happening?" Transaction Tokens (txntoken+jwt, draft-ietf-oauth-transaction-tokens-11) capture the full originating context — user identity, authorisation details, and transaction ID — so every hop in a chain can trust the same root decision without re-authenticating the user.

{
  "iss": "https://tts.cloud-a.example",
  "sub": "alice@corp.example",
  "aud": ["https://api.cloud-a.example"],
  "txn": "a3f8c2d1e5b6...",
  "rctx": {
    "req_ip": "203.0.113.42",
    "req_wl": "spiffe://…/svc/gateway"
  },
  "azd": [{
    "type": "payment",
    "claims": { "amount": "42.00" }
  }]
}

// pkg/txntoken — TTS mints
tts := txntoken.NewIssuer(
  "https://tts.cloud-a.example",
  ttsKey, 5*time.Minute)

tok, _ := tts.Issue(txntoken.IssueOptions{
  Subject:   "alice@corp.example",
  Audiences: []string{"https://api.…"},
  ReqCtx:    &txntoken.RequestContext{
    ReqIP: "203.0.113.42",
    ReqWL: "spiffe://…/svc/gateway",
  },
})

// Downstream service validates
v := txntoken.NewValidator(
  "https://tts.cloud-a.example", ttsPub)
claims, _ := v.Validate(tok)
// claims.Txn, claims.ReqCtx, claims.AzDetails

SPIFFE Client Authentication

Workloads already carry WITs that cryptographically prove their SPIFFE identity. Traditional OAuth client_credentials flows require a client_secret — a credential that must be stored, rotated, and protected. SPIFFE Client Auth (draft-ietf-oauth-spiffe-client-auth-02) eliminates the secret entirely: the WIT itself becomes the client assertion.

grant_type=client_credentials
client_assertion_type=
  urn:ietf:params:oauth:
  client-assertion-type:jwt-bearer
client_assertion=<compact WIT JWT>
scope=read:orders write:payments

// Response
{
  "access_token": "<opaque Bearer>",
  "token_type":   "Bearer",
  "expires_in":   3600,
  "sub": "spiffe://cloud-a.example/svc/billing"
}

// pkg/spiffeclientauth
auth := spiffeclientauth.NewAuthenticator(
  "https://as.cloud-a.example",
  wit.NewValidator(
    "https://idp.cloud-a.example",
    idpPub,
  ),
  time.Hour,
)

tok, err := auth.Authenticate(
  spiffeclientauth.AuthRequest{
    ClientAssertion:     witToken,
    ClientAssertionType: spiffeclientauth.ClientAssertionType,
    Scope: "read:orders",
  },
)
// tok.Sub   = "spiffe://cloud-a.example/svc/billing"
// tok.Token = opaque Bearer string

HTTP Message Signatures: Sign the Request

Instead of attaching a separate proof JWT (the WPT approach), the HTTP request itself is signed. The WIT rides in the Workload-Identity-Token header. The signature covers the method, path, query, and the WIT header — binding proof, identity, and request in one atomic operation.

Live Demo