SPIFFE gives every workload a name, the SPIFFE ID, and a short-lived document that proves it, the SVID. Services present SVIDs to each other instead of sharing static passwords or API keys. The idea is identity based on what a workload is, not a secret someone copied into config.
The problem
Services need to know who is calling them. The usual answers are an IP range, a shared API key, or a long lived client secret in an environment variable. IP ranges are coarse, and secrets get copied, logged and leaked. When one leaks, nothing tells you who used it.
The building blocks
SPIFFE ID. A URI of the form spiffe://trust-domain/workload-identifier. The SPIFFE concepts page gives spiffe://acme.com/billing/payments as an example. The workload identifier names one workload inside its trust domain.
Trust domain. Corresponds to the trust root of a system. Workloads in one trust domain have identity documents that verify against that domain's root keys. The documentation suggests separating workloads by location or by environment, such as staging and production.
SVID. The document a workload uses to prove its identity to a resource or caller. An SVID holds one SPIFFE ID and comes in two formats:
- X.509-SVID: an X.509 certificate. The docs advise using these whenever possible, because tokens can be replayed.
- JWT-SVID: a signed token, useful when an L7 proxy or load balancer sits between workloads and breaks a direct TLS connection.
Trust bundle. A set of CA root certificates a workload should trust. It holds the public key material needed to check both kinds of SVID.
Workload API. The local interface a workload calls to obtain its identity and trust bundle. For X.509 it provides the SPIFFE ID, a private key, a short lived certificate and the bundle. For JWT it provides the ID, a token and the bundle. The workload does not need to know its own identity beforehand.
What changes in practice
- Service to service calls use mutual TLS with SVIDs, so each side verifies the other's SPIFFE ID.
- Authorization rules refer to identities, for example "the payments workload may call the ledger workload", not to addresses.
- Certificates are short lived and renewed automatically, so a stolen one expires quickly.
- There is no per service password to rotate by hand.
Where it fits with OAuth
SPIFFE identifies workloads. OAuth and OIDC handle users and delegated access. They meet where a workload must get an OAuth token without a stored secret, often by presenting a JWT-SVID or a cloud provider identity token to the authorization server. Compare with the client credentials grant, where a stored secret is the usual weak point.
Adoption checklist
- Define trust domains per environment.
- Decide a naming scheme for workload identifiers and keep it stable.
- Prefer X.509-SVIDs for direct service calls, JWT-SVIDs behind proxies.
- Write authorization policy against SPIFFE IDs.
- Monitor certificate issuance and failures.
The SPIFFE concepts page does not cover how attestation works, so read the SPIRE documentation for that part before designing node and workload attestation.
Quick check
Is a SPIFFE ID a secret?
No. It is a name. The proof is the SVID, whose private key stays with the workload.
Why prefer X.509-SVIDs over JWT-SVIDs?
The SPIFFE docs note that tokens can be replayed. Certificates used in mutual TLS prove possession of a private key during the handshake.
Sources
Last reviewed: 19 October 2026.
