> For AI agents: [llms.txt](https://docs.trustedauth.com/llms.txt) provides a Markdown index of this documentation.

# 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.

| Aspect             | User identity                                      | Workload identity                                           |
| ------------------ | -------------------------------------------------- | ----------------------------------------------------------- |
| Represents         | A person                                           | A service, application, or automated process                |
| Authenticates with | Passwords, passkeys, one-time passwords, and so on | Client credentials, a private key JWT, or a SPIFFE JWT-SVID |
| Sign-in style      | Interactive, through a browser or app              | Non-interactive, machine-to-machine                         |
| Managed under      | **Members**                                        | **Workload Identity**                                       |
| Typical use        | Accessing applications and self-service portals    | Calling 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

[📄️Manage identities Use this page to create, view, edit, enable, disable, and delete workload identities. For an introduction to workload identities and the problems they solve, see Workload identities. To configure authentication, claims, and resource server access for a workload identity, see Configure workload identity authentication.](/docs/authentication-and-security/workload-identities/create-workload-identities.md)

[📄️Configure authentication Use this page to configure authentication, claims, and resource server access for a workload identity. For steps to create and manage workload identities, see Create and manage workload identities.](/docs/authentication-and-security/workload-identities/configure-workload-identity-management.md)