Harden API Access with Workload Identities

Workload identities are non-human identities, more precisely, they are identities for a piece of software. As such, they can be relevant at various places in a system architecture both on the user-facing side and in the backend. In other words, workload identities can relate to both API clients and the microservices that compose an API.

Workload identities lend themselves very well to API security because they provide the means to identify a workload. Workloads can use their identities and the related credentials to authenticate to other systems, and to secure a communication on various levels. This article highlights the role of workload identities in securing APIs and API access in particular. At first, it gets the terms straight.

What is a Workload Identity?

A workload identity is a modern type of credential that is fully managed by a trusted party such as the platform the workload is running on. It consists of three components:

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

The workload identifier is, as the name suggests, a unique ID of the workload that allows a system to distinguish one workload from another. The trusted party attests the workload identifier, and optionally other attributes, in a workload credential. The workload credential combined with the workload's private key then provides the means to verify the identifier and the additional attributes.

What is a Workload Credential?

A workload credential is a short-lived document with verifiable data about a workload which is optionally linked to the workload's private key. If there is a linked private key, a workload needs to provide proof of control over the linked key in addition to its workload credential when authenticating to other workloads. Implementations use strong asymmetric cryptography for that.

Typically, workloads receive their credentials from the platform such as a cloud provider or Kubernetes. As part of the process, the platform performs some attestation checks to retrieve an accurate workload identifier and to prevent impersonation. When the platform deems the workload trustworthy it issues a credential with the workload identifier.

The platform automatically renews workload credentials. Consequently, workload identities enable short-lived credentials without workloads having to deal with the complexity of credential management.

There are ongoing initiatives aiming to standardize efforts concerning workload identities. Two examples are WIMSE and SPIFFE/SPIRE. WIMSE aims to establish best practices for using workload identities as part of data security solutions. The goal of SPIFFE and the related implementation SPIRE is to provide interoperability so that solutions can use workload identities anywhere, including on-premise servers.

What are the Use Cases?

Workload identities are primarily an authentication solution for applications. As such they enable the following main use cases for APIs:

• Strengthening client credentials.
• Confidential connections.
• Workload authorization.

Strengthening Client Credentials

Workload identities use strong asymmetric cryptography and at the same time offload credential management from workloads. Consequently, they are a very handy tool for strengthening client credentials. You can, for example, replace any plain passwords or API keys with workload credentials. This means, you could use workload identities to connect to a database and have the platform renew the credential on a regular basis. Such an update removes many security risks related to stolen or leaked client credentials. On top of that, workload identities are useful for securing internal connections.

Confidential Connections

Service meshes such as Istio use workload credentials to automatically upgrade internal HTTP connections to use mutual transport level security (mTLS). The TLS channel encrypts data between internal services. Typically, a middleware such as sidecars automatically renew the workload credentials, that is the TLS certificates.

Workload Authorization

A logical consequence of being able to authenticate workloads is the enforcement of authorization policies for workloads. This means, that you can define policies and allow or deny workloads to communicate with each other. The platforms often support workload related policies out of the box. For example, you can configure roles for service accounts in AWS and grant a workload access to certain features in an AWS service. The AWS service then enforces the rules by checking the roles.

What are the Limitations?

Workload identities do not provide a complete security solution for APIs. For example, workload identities do not identify users or deal with privacy issues such as user consent. Consequently, workload identities are not a replacement for the business authorization rules that you implement in APIs, but a complement.

APIs usually always need to apply an authorization policy after authenticating a caller, workloads and users alike. Authorization is the biggest risk according to OWASP. Without care, APIs can reveal unauthorized information despite using workload identities, e.g. for confidential connections.

For a full zero trust API solution, combine strong client authentication with API authorization. Use the OAuth authorization framework and integrate workload identities in existing or new OAuth flows to increase their security qualities. The following section provides some guidance on that topic.

How to Use Workload Identities With OAuth?

OAuth is a protocol that provides API clients with access tokens. To retrieve an access token, best practices advocate using confidential clients because they reduce the risk of the authorization server issuing tokens to malicious clients. Confidential clients are API clients that can securely store a client credential with which they can authenticate at the authorization server when requesting access tokens.

Strong Backend Client Credentials

The simplest form of client credentials in OAuth is a client ID and secret which basically is equivalent to a username and password that the client presents to the authorization server. The secret may be sufficient in some scenarios. If a malicious party discovers the secret, they might be able to misuse it for a considerable time.

OAuth also supports more advanced authentication methods for clients which use asymmetric cryptography. One example is certificate-based client authentication defined in RFC 8705, where the client can use a client certificate and mutual TLS connection to authenticate to the authorization server. Another example of advanced client authentication is assertion-based client authentication defined in RFC 7523 and OpenID Connect, where the client presents a JWT-encoded credential.

Workload credentials can have various formats. The main two formats are X.509 certificates and JWTs. Since OAuth already supports client authentication with those formats, you can use existing specifications to integrate workload identities into OAuth and get more secure and convenient client credentials. The authorization server is then responsible to apply a policy for each workload, authorize requests and issue the correct access tokens.

Strong External Client Credentials

Workload identities and strong credentials are not limited to backend clients. For example, major mobile platforms have an integrated attestation system that can verify the identity of mobile applications, and produce a verifiable receipt, the attestation JWT. Mobile applications can request an attestation via SDKs from the mobile platform. The mobile application can then use the attestation JWT to authenticate at the authorization server, e.g., on a one-time basis when dynamically registering a client, or continuously as part of OAuth messages.

In other cases like IoT devices you may use X.509 certificates as strong client credentials. For a B2B integration you may be able to choose between X.509 certificate or JWT assertions.

Example

To use X509 workload identities you may need to deploy an extra subsystem like a service mesh or SPIRE. However, some platforms, Kubernetes in particular, have built-in support for workload credentials, i.e., they issue service account tokens. They allow you to upgrade to strong OAuth client credentials without deploy nay additional infrastructure. To do so, you need first trust the service account issuer and configure the workload identifier in the authorization server.

Backend clients such as microservices can then use their service account tokens as JWT assertions in any OAuth message that requires client authentication. For example, clients can use workload identities and JWT assertions in the client credentials flow to get access tokens as the following example illustrates:

POST /token HTTP/1.1
HOST: login.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion=eyJhbGciOiJQUzI1NiJ9.eyJpc3MiOiJ3b3JrbG9hZC1pZGVudGl0eS1pc3N1ZXIiLCJzdWIiOiJhcGktc2VydmljZSIsImF1ZCI6Imh0dHBzOi8vbG9naW4uZXhhbXBsZS5jb20iLCJleHAiOjE3NDYwNTA0MDB9.l-ZMRZa6_FCXaHucfjqdH4jge3xwIiGCD5mdWbDyz_NYzBRbB-ut-ht7wwDmWn-NDY8Ojv3yA_VPXiGxvZg-4XyRRvvuVBlzQVoauv3CcrnxuCpTqU2sc_GTSM6l6aeMhUMMpQI1zSpL6smOCjRaFYxtPLmrQ3WMfyUgAu23V_Fm4DDYwReiuxLLYBeRkxyU_wV3ff1CTEz0KF2DIW7taRxmqXRRoFY84g2vcMHlclRtsxxz9f1ABeqJb8miIwrnQcq5rVFEcA769NL60LNgTsb8KUWNmZC4hTJdHRoyVLIeD2_GGiwp4YSTi6YEJhTUegORzzc8ckinJsleAZQXXg

Refer also to the Workload Identity Practice with regard to the current common practice on how to use workload identities in OAuth.

Summary

Workloads identities provide strong client credentials for applications. They enable client authentication using strong asymmetric cryptography without the overhead of credential management. Workload credentials are short-lived and automatically renewed, to ensure good manageability that scales. A common and well-known use case of workload identity is encrypting (internal) connections.

Workload identities are primarily an authentication solution. They do not provide authorization solutions for APIs. Therefore, when implementing API security, base your solution on OAuth and access tokens to ensure the correct API authorization. Then use workload credentials for strong client authentication. You can scale these techniques to many APIs and API clients with good manageability.

Last updated: 2025-05-27

Judith Kahrer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Email

Subscribe

I agree to Curity's Privacy Policy

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial