# OAuth Transaction Tokens (Txn-Tokens)

Source: https://startwithidentity.com/standards/oauth-transaction-tokens/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What it is

Transaction Tokens (Txn-Tokens) are short-lived, signed JWTs that "maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain", in the words of the [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/). A Transaction Token Service (TTS) mints one when a request enters the domain, typically at an API gateway, and every internal service that handles the request verifies it rather than receiving the caller's original access token.

The problem is the internal call chain. An external request arrives with an OAuth access token and then touches five, ten or fifty microservices. Most architectures either forward the external token downstream (any service that logs or leaks it hands an attacker a replayable credential with the full external scope) or drop it and rely on network location (no service past the gateway knows which user the work is for). Txn-Tokens replace both with a token scoped to one transaction, lasting minutes. The [glossary entry](https://startwithidentity.com/glossary/transaction-tokens/) has the one-paragraph version.

## Status (November 2026)

The latest revision is draft-11, dated 30 July 2026, read from the IETF datatracker on 5 November 2026. Its working-group state is **WG Consensus: Waiting for Write-Up**: the OAuth Working Group agrees on the text and the shepherd write-up is pending before it goes to the IESG. The [OAuth WG milestones](https://datatracker.ietf.org/wg/oauth/about/) list "Submit Transaction Tokens to the IESG" for December 2026. It is Standards Track, not an RFC. The authors are Atul Tulshibagwale ([CrowdStrike](https://startwithidentity.com/vendors/itdr/crowdstrike-falcon-identity/)), [George Fletcher](https://startwithidentity.com/experts/george-fletcher/) (Practical Identity LLC) and Pieter Kasselman (Defakto Security).

Consensus means the design is unlikely to change shape, but claim details can still move during IESG review. Pin the revision.

## How it works

A concrete flow for an order placed through a public API:

1. **External call.** A client calls `POST /orders` at the gateway with an OAuth access token for the user.
2. **Token request.** The gateway calls the TTS using [token exchange (RFC 8693)](https://startwithidentity.com/glossary/token-exchange/): `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`, `requested_token_type=urn:ietf:params:oauth:token-type:txn_token`, `audience` set to the trust domain name, `scope` set to the narrow purpose (for example `orders.create`), and the external access token as `subject_token`. The gateway authenticates to the TTS as a workload, for example with mutual TLS or a [SPIFFE](https://startwithidentity.com/glossary/spiffe/) credential.
3. **Mint.** The TTS checks the subject token is unexpired and its own issuance policy, then returns a Txn-Token.
4. **Propagate.** The gateway calls the orders service with the Txn-Token in the `Txn-Token` HTTP header. The orders service calls inventory and payments with the same Txn-Token. The draft forbids carrying it in the `Authorization` header, because that header may already hold the caller's workload credential.
5. **Verify at each hop.** Each service checks the signature, that `aud` is its own trust domain, that `exp` has not passed, and that `scope` and the context permit the action it is about to take.

The JWT header must carry `typ` `txntoken+jwt`. Body claims:

| Claim | Requirement | Meaning |
|---|---|---|
| `aud` | Required | The trust domain where the token is valid; must not be accepted elsewhere |
| `iat`, `exp` | Required | Issue and expiry times, expected to be minutes or less |
| `txn` | Required | Unique transaction identifier (as in RFC 8417) |
| `sub` | Required | The principal, unique within the trust domain |
| `scope` | Required | The purpose of this transaction, chosen by the TTS and possibly narrower than the external scope |
| `req_wl` | Required | The workload that requested the token |
| `tctx` | Recommended | Transaction context that stays immutable along the chain, such as an order amount |
| `rctx` | Recommended | Request context such as the original IP address or authentication method |
| `iss` | Optional | Often omitted, because keys are known within one domain |

Two rules in the draft are worth memorizing. A Txn-Token is **not an authentication credential**: a workload must not use it to prove its own identity. And it is **not an access token**: it records the context of one transaction, not a grant to a client. Services still authenticate each other with workload identity ([WIMSE](https://startwithidentity.com/glossary/wimse/), mTLS or SPIFFE) and use the Txn-Token for the authorization decision.

For scheduled or internally started work with no inbound token, the requesting service may present a self-signed JWT as the subject token. That path deserves the strictest TTS policy, since it is where a compromised internal service could mint context for any user.

## What it solves for AI agents and SaaS

For SaaS platforms built from many services, Txn-Tokens give least privilege inside the perimeter. A stolen Txn-Token is valid in one trust domain, for one purpose, for minutes. Signed `tctx` means a downstream service can trust that the order amount it sees is the amount the user submitted, not a value changed by a compromised hop. Every service logs the same `txn`, so incident responders can follow one request end to end.

For AI agents, the internal call chain is the tool chain. An agent platform that receives a user request and calls retrieval, code execution, ticketing and email tools can mint a Txn-Token that names the user, the agent workload in `req_wl` and a narrow purpose, and require every internal tool service to check it. The IETF WIMSE working group's [AIMS draft](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) (revision -01, 2 November 2026) lists Transaction Tokens among the existing standards it maps agents onto, and SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) places them under chained delegation and audit.

Limits: one trust domain only, and the draft does not define how an agent's natural-language task becomes a `scope`. That translation step, where [prompt injection](https://startwithidentity.com/glossary/prompt-injection/) becomes over-broad access, is still undefined by any standard.

## Adoption signals (verified)

We found no vendor documentation, as of 5 November 2026, that announces general availability of a Transaction Token Service built to this draft. The verifiable signals are standards-track: working-group consensus, the December 2026 IESG milestone, and citation in the AIMS draft. Authors from CrowdStrike, Practical Identity and Defakto Security indicate where implementations are likely to appear first, but that is a signal, not a deployment.

## How to implement or evaluate

- **Start at the gateway.** Run the TTS as a small internal service next to your API gateway or service mesh ingress. Only the gateway, and a short allowlist of internal schedulers, should be able to request tokens.
- **Design purposes, not scopes.** Define `scope` values per business transaction (`orders.create`, `refund.issue`), not per API. The draft lets the TTS choose a value narrower than the external scope.
- **Keep lifetimes in minutes.** Long-running jobs should request new tokens per step rather than one long-lived token.
- **Verify everywhere.** A service that does not check the Txn-Token turns the whole design back into network trust. Build verification into a shared middleware.
- **Separate authentication.** Pair Txn-Tokens with workload identity for service-to-service authentication; see [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/).
- **Log `txn`, `sub` and `req_wl`** on every call. That gives you the audit trail agent deployments otherwise lack.

## Pitfalls

- **Treating it as a bearer access token** and accepting it at external APIs. The draft forbids both.
- **A TTS that mints for anyone.** If any workload can request a token for any subject, the TTS becomes a privilege escalation service. Restrict requesters and log issuance.
- **Copying the whole external scope.** That keeps replay value high and defeats the design.

## Related

[WIMSE](https://startwithidentity.com/standards/wimse/) (workload-to-workload authentication; its Workload Proof Token binds a Txn-Token with the `tth` claim), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide, and the [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Glossary: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/).

## Who wrote it

The draft is by [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/), [George Fletcher](https://startwithidentity.com/experts/george-fletcher/) and Pieter Kasselman. More in the [experts directory](https://startwithidentity.com/experts/).