Skip to main content

Workload identities

A workload identity is a non-human identity that represents a service, application, or automated process rather than a person. Workload identities let your machines and services authenticate to IDaaS and call your protected APIs without a person being present. They support machine-to-machine (M2M) scenarios such as backend services, batch jobs, CI/CD pipelines, and agents.

This section explains what workload identities are, the problems they solve, and how to create and manage them.

User identities and workload identities​

Both user identities and workload identities are first-class identities in IDaaS, but they represent different kinds of actors and authenticate in different ways. A user identity represents a person who signs in interactively, while a workload identity represents software that authenticates on its own.

AspectUser identityWorkload identity
RepresentsA personA service, application, or automated process
Authenticates withPasswords, passkeys, one-time passwords, and so onClient credentials, a private key JWT, or a SPIFFE JWT-SVID
Sign-in styleInteractive, through a browser or appNon-interactive, machine-to-machine
Managed underMembersWorkload Identity
Typical useAccessing applications and self-service portalsCalling protected APIs and automating backend workflows

What you can do with workload identities​

Workload identities give your automated systems a managed, auditable identity of their own, so you no longer have to share a user account or embed long-lived static secrets across services. With workload identities, you can solve several common problems:

  • Give services their own identity. Assign each service a distinct identity instead of reusing a person's account, so access reflects what the software does, not who set it up.
  • Authenticate without shared secrets. Use short-lived, cryptographically verifiable credentials such as a private key JWT or a SPIFFE JWT-SVID instead of a shared password or a static client secret.
  • Control API access with scopes. Grant each workload only the resource server scopes it needs through client credentials grants.
  • Group and manage at scale. Organize workloads with groups, then enable, disable, or delete them without affecting user accounts.
  • Audit machine access. Track every authentication a workload makes, including failed attempts, so you can detect misconfiguration and misuse.

Example scenario​

Consider a payments service that runs as a set of containers and must call an internal orders API. Rather than sharing an administrator's account or hard-coding a secret into each container, you create a workload identity named payments-service.

You configure the workload to authenticate with a SPIFFE JWT-SVID and allow the SPIFFE ID pattern spiffe://prod.example.com/payments/*, so any container instance in that path can authenticate as the same workload identity. You then grant the workload the orders.read and orders.write scopes on the orders resource server. Each container now obtains a short-lived access token on its own, calls the orders API with only the scopes it needs, and every request is recorded in the workload's audit history. If a container is compromised, you disable the workload identity to cut off access immediately, without touching any user account.

How workloads authenticate​

When you create a workload identity, IDaaS automatically provisions an associated OpenID Connect (OIDC) and OAuth server application for it. The workload uses this application to obtain access tokens through the OAuth client credentials flow, and you choose how strongly it authenticates by setting the application's client authentication method:

  • Client secret. The workload presents a shared secret. This is the simplest method but relies on a long-lived static value.
  • Private key JWT. The workload signs a JWT with its private key, and IDaaS verifies it with the corresponding public key. No shared secret is transmitted.
  • SPIFFE JWT-SVID. The workload presents a SPIFFE-issued token that IDaaS validates against a trust domain and a set of allowed SPIFFE IDs.

What SPIFFE is and why it matters​

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard that gives each workload a platform-neutral identity called a SPIFFE ID, such as spiffe://prod.example.com/payments/api. A SPIFFE-compatible system (for example, SPIRE) issues each workload a short-lived, cryptographically signed credential called an SVID (SPIFFE Verifiable Identity Document). The JWT form of an SVID, a JWT-SVID, carries the workload's SPIFFE ID.

SPIFFE matters because it lets workloads authenticate with strong, automatically rotated credentials instead of shared secrets, and it provides a consistent identity across clouds, clusters, and platforms. By trusting a SPIFFE trust domain and matching on SPIFFE IDs, IDaaS can grant access based on a workload's verifiable identity rather than a secret that could be leaked or copied.

Topics in this section​