Tokens, APIs, workloads: the invisible identities your architecture should map

Identity in an information system is usually discussed in terms of people: employees, administrators and contractors.

Yet a growing share of access is performed directly by software. A microservice calls an API, a pipeline deploys an application, a serverless function accesses storage, or an agent queries a cloud service.

Those components also have identities, or at least mechanisms that establish who they are and what they are allowed to do.

NIST has finalized IR 8587 on protecting tokens and assertions. The final version explicitly adds workload identity considerations and reinforces short-lived authorization mechanisms rather than permanent technical credentials.12

The architectural consequence is straightforward: mapping human accounts is no longer enough to map trust.

An application can have its own identity

A technical identity may take the form of a temporary cloud role, certificate, OAuth token, Kubernetes identity, managed identity or assertion issued by an identity provider.

The same question applies in every case: which component can prove an identity, to whom, and in exchange for what access?

NIST IR 8587 discusses identity providers, authorization servers and systems consuming tokens and assertions.1 NIST's federation guidance describes relationships between identity providers and relying parties.3

These are architecture relationships, not merely IAM settings.

Add the trust chain to the application view

A conventional application view may show:

application → API → database

A trust view adds:

workload → identity provider → temporary authorization → API → privilege → resource

This enables different questions. Who establishes the identity? Which application can request access? Which service accepts it? How long is it valid? What privilege is granted? Which resource becomes reachable?

Two communicating applications may therefore depend on a third component invisible in a network-flow view: the authority establishing trust between them.

Temporary authorization can still be critical

An authorization may live for only a few minutes. During that period it can allow an API call, data access or a resource change.

IR 8587 addresses token and assertion protection, verification, signing-key management and lifecycle controls.1

Lifetime therefore becomes a useful architecture attribute. A relationship saying A can access B may also need to describe the mechanism, intended audience, validity period and revocation path.

Mapping the blast radius of a machine identity

Consider service A, which can call API B. API B can write to database C. Pipeline D can deploy a new version of service A.

The application view shows:

A → B → C

The trust view reveals:

identity provider → identity A → authorization → B → privilege → C

and:

pipeline identity D → deployment platform → A

Compromising the pipeline can therefore create an indirect path to C even though D has no direct network flow to the database.

This is the value of mapping trust relationships: it exposes paths of control that are not network paths.

Practical case: a Kubernetes microservice

Imagine an order-processing application made of several microservices.

The billing service needs to call a payment API. The workload proves its identity to a trusted provider and obtains a short-lived authorization intended for that API.

The chain becomes:

pod → workload identity → identity provider → token → payment API → authorization

Six pieces of information are useful to document:

1. Workload — which component requests access?
2. Issuer — who attests its identity?
3. Audience — which service should accept the token?
4. Privilege — which operations become possible?
5. Lifetime — how long can the authorization be used?
6. Revocation — how is the relationship cut during an incident?

The result is useful both for architecture and incident response.

Federation creates trust boundaries

NIST SP 800-63C-4 describes federation as a model in which an identity provider can supply authentication information to separately administered relying parties.3

In an enterprise, those boundaries can cross public cloud, SaaS, Kubernetes clusters, internal APIs and partner services.

A useful map therefore distinguishes who administers a component from which identity authority the component trusts.

Organizational boundaries and trust boundaries do not always coincide.

Authentication and authorization are different relationships

NIST's Digital Identity Guidelines separate authentication mechanisms from federation and assertion mechanisms.34

Authentication establishes an identity.

A token or assertion carries trusted information.

Authorization determines what that identity may do to a resource.

Mapping those relationships separately avoids reducing everything to a vague "uses the IdP" dependency.

A machine identity and trust view

For cloud and distributed architectures, a dedicated view can bring together workloads, identity providers, authorization servers, managed identities, technical roles, target APIs and resources, privileges, lifetimes and revocation mechanisms.

The objective is not to store sensitive authentication material in an IS map. What matters is documenting the existence of the relationship, its authority, scope and blast radius.

Seven questions to ask

1. Which applications and workloads have their own identity?
2. Which components can issue tokens or assertions trusted by the information system?
3. Which APIs accept those identities, and with which privileges?
4. Which machine-to-machine communications still rely on permanent mechanisms?
5. Do several workloads share the same identity?
6. Can a compromised trust relationship be revoked quickly?
7. Can you visualize the blast radius of a technical identity?

Map trust, not only users

Human identities remain essential, but they are only part of the actors able to perform actions in a modern information system.

As architectures become more distributed, automated and cloud-based, software increasingly obtains authorization to act on other software.

An inventory knows that an API exists. A trust map should also explain who can obtain the right to call it, through which mechanism, and how far that access can lead.