Workload Identities: Bridging Infrastructure and Application Security

Infrastructure security has long been about protecting networks, hosts, and cloud platforms. Application security focuses on securing APIs, data flows, and business logic to protect critical assets. Both approaches are critical, but they can’t provide complete protection on their own. When isolated from each other, there is a higher risk that attackers can exploit the security gaps in either layer, which is why workload identities should be employed to serve as a bridge that unifies both layers.

The Two Security Worlds: Infrastructure vs. Application

Infrastructure security is about protecting the foundation, including measures such as network segmentation, least-privilege identity and access management (IAM) roles, container isolation, and applying zero-trust principles at the infrastructure level. Application security works higher up in the stack, closer to data and user interactions. It deals with authentication, authorization, token management, session handling, and API protection. 

If pursued separately, weak security gaps may exist. Application teams may assume the infrastructure is already secure, while infrastructure teams might not always see the fine-grained context the application relies on.

What Is a Workload Identity?

A workload identity, or a non-human identity, is an identity assigned to a piece of software, such as an API client, microservice, or scheduled job, rather than a human person. Each workload is associated with a unique set of attributes that distinguish it from others and enables it to exchange identity information with other workloads. A workload identity consists of three components:

• The workload identifier
• The workload credential
• Optionally, a private key linked to the workload credential

The workload identifier contains a unique ID that differentiates it from others. The workload identifier, along with other attributes, is attested by the trusted third party in a workload credential. The workload credential, together with the workload's private key, then enables the verification of the identifier and the additional attributes.

What is a Workload Credential?

To establish trust, workloads receive credentials from credential issuers and can use them to authenticate when interacting with systems and services. Workload credentials are documents that a recipient can cryptographically verify and authenticate. When used in this way, the recipient receives a high level of assurance of the caller's identity. 

Workload credentials are typically short-lived and automatically managed by the underlying platform, reducing exposure and strengthening security. A workload stores its credentials in memory or on disk and presents them as proof of ownership when communicating with other workloads.

Common credential issuers include Kubernetes, cloud providers such as AWS, Azure, and Google Cloud, as well as open-source solutions like SPIRE, which can issue interoperable JSON Web Token (JWT) and X.509 credentials for workload-to-workload authentication.

For example, a microservice named api-service could be issued a JWT that asserts the service’s identity. Such a credential could look similar to this:

eyJhbGciOiJQUzI1NiJ9.eyJpc3MiOiJ3b3JrbG9hZC1pZGVudGl0eS1pc3N1ZXIiLCJzdWIiOiJhcGktc2VydmljZSIsImF1ZCI6Imh0dHBzOi8vbG9naW4uZXhhbXBsZS5jb20iLCJleHAiOjE3NDYwNTA0MDB9.l-ZMRZa6_FCXaHucfjqdH4jge3xwIiGCD5mdWbDyz_NYzBRbB-ut-ht7wwDmWn-NDY8Ojv3yA_VPXiGxvZg-4XyRRvvuVBlzQVoauv3CcrnxuCpTqU2sc_GTSM6l6aeMhUMMpQI1zSpL6smOCjRaFYxtPLmrQ3WMfyUgAu23V_Fm4DDYwReiuxLLYBeRkxyU_wV3ff1CTEz0KF2DIW7taRxmqXRRoFY84g2vcMHlclRtsxxz9f1ABeqJb8miIwrnQcq5rVFEcA769NL60LNgTsb8KUWNmZC4hTJdHRoyVLIeD2_GGiwp4YSTi6YEJhTUegORzzc8ckinJsleAZQXXg

Which decodes to the following values:

{
    "alg":"PS256"
}
{
    "iss":"workload-identity-issuer",
    "sub":"api-service",
    "aud":"https://login.example.com",
    "exp":1746050400
}

The service can then use the JWT to identify itself in workflows that support this credential format. For example, when running an OAuth flow to get tokens from an authorization server. 

Workload Identities Use Cases

• Service meshes use workload credentials to encrypt internal messages and outsource the complexity of key management from workloads.
• Administrators can use service meshes to configure which workloads can call each other, using workload identities.
• Developers can use workload credentials explicitly in their code to send or receive a workload credential.
• Workload credentials enable organizations to replace weak credentials like API keys or passwords. They are also short-lived and automatically renewed by the credential issuer.

In some cases, workload credentials are automatically handled by service mesh components like sidecars. In other cases, a workload may need to explicitly send a workload credential. Below you can see an example of two workloads using workload credentials in a client assertion flow:

1. The platform issues a JWT credential. This is a service account token with a configurable lifetime. The platform will automatically renew it before it expires.
2. When workload A needs to prove its identity to workload B, it presents the JWT credential as proof of identity. 
3. The platform also provides a mechanism for recipients like workload B to verify the JWT. This ensures the credential hasn’t been tampered with and that it represents the expected identity. 
4. Workload B can use a library to fetch the public key from a JSON Web Key Set (JWKS) and validate the credential with minimal code. After verification, Workload B applies a policy to determine what actions Workload A is authorized to perform.

Securing Workloads 

The first step is to look at the big picture. In most environments, there are many different workloads, with the most critical ones exposing business data through APIs. Behind these APIs lies an ecosystem of supporting components, including API gateways, observability tools, and continuous delivery systems. Each of these connections must be secured, and traditional approaches such as static API keys introduce vulnerabilities that attackers can exploit.

Non-human identities exist to make these system-to-system connections stronger and easier to trust. They use verifiable credentials instead of static secrets, giving each workload a reliable way to prove who it is.

These identities aren’t limited to internal systems either. A mobile app, for instance, can use attestation to confirm its integrity, and two partner APIs can authenticate each other using signed credentials.

Bridging the Gap: Authorization Using OAuth

Workload identities provide a strong foundation for security, but they do not address several key issues, such as user authentication and consent, or best practices for API clients, including those that run in browsers. A strong security solution needs to apply security at multiple endpoints, not just in backend components.

In particular, workload identities are not sufficient to secure APIs correctly. APIs must accurately evaluate user identities and apply fine-grained authorization decisions. Without this additional layer, APIs risk granting over-privileged access to business data. To avoid vulnerabilities, APIs must employ a security design that extends beyond workload-level trust and also incorporates business authorization.

OAuth 2.0 provides a widely adopted framework for authorization and business-level protection. Mature APIs rely on token-based security, typically using access tokens that carry claims about the requesting user or system.

These claims represent pieces of contextual information, such as user roles, permissions, or attributes that the API can interpret to make authorization decisions. By validating these claims, the API determines whether a request should be granted and what data can be returned. In this way, tokens provide the critical context needed to ensure that requests are properly verified and access is correctly controlled.

OAuth Clients and Workload Credentials

Workload security and API authorization can reinforce each other. On one level, APIs rely on access tokens. But by introducing workload credentials and identities, the security of those tokens can be significantly strengthened.

Traditionally, a client connects to the authorization server and authenticates (for example, by presenting a password or secret) to obtain access tokens. With workload credentials, this process is hardened. Instead of static secrets, the workload uses a dynamic certificate or JWT to authenticate itself directly with the authorization server.

This approach allows the authorization server to issue sender-constrained tokens, which are access tokens that are cryptographically bound to a specific workload. 

As a result, even if a token is intercepted, it cannot be reused by an unauthorized party. The Workload Identity in Multi-System Environments (WIMSE) working group is currently designing draft specifications that combine workload identities with token-based access control.

When workload credential security is combined with business-level authorization, the outcome is a more resilient, zero-trust solution that enforces both workload and user-level protection. When you combine workload identities with OAuth, you get a complete API security solution. In particular, you are no longer restricted to allow/deny rules per component. Instead, you can implement partial access according to your particular business rules.

Combine Tools and Techniques

1. Start with OAuth 2.0 to protect API data and users
2. Use workload identities to harden backend connections
3. Use the strongest security available in client environments 
4. Stay up-to-date with best practices

Conclusion

Combining workload identities with OAuth provides a stronger security foundation, covering clients, APIs, gateways, and backend systems. Together, they create the basis for a practical zero-trust approach. The key is to treat authorization as a first-class concern so that every request is evaluated with the right context. Just as important is leveraging all available security tools together, rather than in isolation, to build a defense that is both consistent and adaptable.