IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Identity across microservices — who is calling whom?
Maya orders biryani in a food-delivery app and taps "pay" once. Her request passes through many services: orders, payments and a ledger. The last service never saw her log in. Your goal: make every service know who the request is for and who is calling.
- Check Maya's token fully, once, at the edge (the API gateway).
- Do not forward her token. Trade it for a narrower token at each hop.
- The new token names the user (sub) and the calling service (act).
- Services prove who they are with mutual TLS.
One request, many services
A microservice design splits one big app into many small services. They call each other over the network. So identity must now travel from service to service. If Payments trusts whoever knocks, anything on the network can pretend to be Orders.
Check once at the edge
The edge is your API gateway. It is the one place where Maya's user token is fully checked. It checks the signature, expiry, audience and scopes (see the API gateway lesson). Everything behind it is the internal zone.
The tempting mistake is to treat "internal" as "safe". Zero trust says the opposite. NIST (a US standards body) says in SP 800-207: give no trust just because of network location. Every hop must still prove who it is. (See zero trust and context.)
Do not forward the user's token
How does identity travel inward? The lazy way is to copy Maya's token and send it to every service. This is dangerous. The token was made for the gateway, and it has all her scopes. If Orders also forwards it to a delivery partner and an outside tax API, every one of them can act as Maya everywhere, and so can anything that breaks into one.
The careful way is token exchange (RFC 8693; see token exchange). At each hop, a service trades its token for a new, narrower one. The new token is only for the next call. It is audience-bound, so it works for just the next service. It also names both parties. The user is in the sub claim. The calling service is in the act ("actor") claim. It reads: "for Maya, acting via Orders."
a lift key card in an office tower. At reception you show your ID once. You do not get a master key. You get a card for the one floor you are visiting, printed with your name and your host's name.
Proving the service: mTLS and SPIFFE
The exchanged token says who the request is for. What proves the caller really is Orders? Mutual TLS does. Both sides show a certificate, so Payments knows it is talking to Orders before it reads anything.
Setting this up by hand for every service does not scale. So a mesh uses SPIFFE, an open standard for workload identity. Each workload gets a short-lived identity document, renewed automatically (see SPIFFE and the mesh). Now each hop has two proofs: the token (who it is for) and the workload identity (who is calling).
Here is the path of Maya's order:
- The gateway fully checks Maya's token: signature, expiry, audience and scopes.
- Orders trades that token for one bound to Payments.
- Orders calls Payments over mTLS. Each side shows its workload identity.
- Payments trades again for a token for Ledger, with sub=Maya and act=Payments.
- Ledger records the payment with the whole chain of who called whom.
Zara finds a ₹4,800 refund that nobody owns. With forwarded tokens, every log line says only "Maya". After the team switches to token exchange, the trace reads: "Ledger recorded a refund for Maya. Payments called it. Orders called Payments. The gateway called Orders."
Go deeper: another way: transaction tokens
Exchanging a token at every hop works, but it adds a call to the token service each time. A newer idea is the transaction token. At the edge, one internal service trades the user token for a short-lived signed token that describes the whole request. It names the user and what the request may do. Every service inside passes it along.
As of October 2026 this is still an IETF draft (draft-ietf-oauth-transaction-tokens, revision 11), not an RFC. Read it as a design to watch.
Go deeper: how much does your system need?
A small system with one team can start with mTLS between services and a gateway check. Add token exchange when a service calls others for a user, or when you must show who did what. Add a mesh when you have too many services to manage certificates by hand. Do not add all three on day one. Each one adds work to run.
🧪 Interactive lab — enable JavaScript to play with this one.
Build an exchanged token and read its sub and act claims with Token Exchange. Inspect the workload IDs behind mTLS with SPIFFE Scan.