Zero Trust Applied to APIs

Zero Trust for APIs: Explicitly check and decide on a per-request basis

Central principle

No location grants implicit trust; each access must be authenticated, authorized, limited and continually evaluated.

In-depth edition - study material and professional reference

radio_button_unchecked Chapter presentation

Traditional security architecture was built around network boundaries. Users, servers and applications located within a corporate network received, explicitly or implicitly, a greater level of trust. This model lost effectiveness as APIs began to connect clouds, partners, mobile devices, suppliers, SaaS applications, data centers and ephemeral workloads. The origin of a connection remains relevant as a signal, but is no longer sufficient to decide whether an operation should be authorized.

Zero Trust is a set of principles and an architectural strategy based on eliminating implicit trust. Resources are protected individually or in small groups; subjects and devices are identified; access decisions use current policies and information; communications are protected; and telemetry is used to continually improve posture. The objective is not to distrust people in a generic way, but to prevent location, ownership or past authentication from producing broad and permanent authorization.

APIs are a natural point to apply Zero Trust because they already materialize operations, identities, data and policies. An API Gateway can act as a Policy Enforcement Point at the edge, while service meshes apply controls between workloads. Identity providers issue credentials and tokens; posture mechanisms provide context; policy drivers make decisions; and observability records what happened. However, purchasing a gateway, enabling mTLS, or requiring MFA does not alone create a Zero Trust architecture .

This chapter connects the fundamentals of identity, OAuth, mTLS, API Gateways, policies, service mesh, Kubernetes and observability studied previously. The focus is technical and operational: how to model subjects and resources, how to evaluate each request, how to limit privileges, how to reduce lateral movement, how to handle failures in decision components and how to evolve the deployment without interrupting critical integrations.

How to study this chapter

For each flow, identify: subject, resource, action, context, identity source, decision engine, enforcement point and recorded evidence. This decomposition transforms the term Zero Trust into verifiable architecture.

Learning Objectives

• Explain Zero Trust without reducing it to product, VPN, mTLS or multi-factor authentication.
• Relate the principles of NIST SP 800-207 to the design of corporate APIs.
• Distinguish Policy Engine , Policy Administrator , Policy Enforcement Point, PDP , PIP and PAP .
• Model human identities, applications, workloads, devices and sessions.
• Apply contextual authorization and least privilege to API operations and data.
• Understand bearer tokens, pegged tokens, mTLS, and DPoP in the context of replay reduction.
• Design Zero Trust controls in API Gateways, service meshes and Kubernetes.
• Combine microsegmentation , controlled egress, data protection and observability.
• Define availability, caching, fail-open , and fail-closed strategies for policy decisions.
• Plan a maturity journey with metrics, testing, governance and adaptive response.

Chapter structure

• 34.1 What Zero Trust is and isn’t
• 34.2 Logical principles and components
• 34.3 Protected resources, subjects and surfaces
• 34.4 Decision by request and dynamic trust
• 34.5 Human identity, application, workload and device
• 34.6 Tokens, mTLS and proof of ownership
• 34.7 Granular authorization and policy architecture
• 34.8 API Gateways as enforcement points
• 34.9 Service mesh, Kubernetes and east-west traffic
• 34.10 Microsegmentation , egress and data protection
• 34.11 Telemetry, risk and adaptive response
• 34.12 Availability, governance, maturity and troubleshooting
• Summary, checklist, exercises, glossary and references

radio_button_unchecked 34.1 What Zero Trust is and isn’t

Zero Trust is a security model, a set of design principles, and a coordinated management strategy. Its premise is that threats can exist within and outside traditional boundaries and that no element should be given implicit trust solely by location, ownership or organizational relationship. Protection moves from broad network segments to specific users, devices, workloads, applications, data and resources.

The term does not mean blocking everything, manually re-authenticating the user with every click, or completely eliminating private networks. It means that each access needs to be supported by identity, policy and context sufficient for the risk of that action. A request to read public data and an irreversible financial transaction do not necessarily require the same authentication strength, the same set of signals or the same authorization validity time.

There is also no single product called Zero Trust. Identity providers, gateways, service meshes, EDRs, policy engines, data catalogs, SIEMs and observability platforms can participate in the architecture. Value arises from the coherent integration between these components, the quality of policies, the coverage of resources and the ability to measure and react to deviations.

An internal network can still reduce exposure, and a firewall remains useful. The mistake is to transform presence on this network into sufficient proof of identity and authorization. Similarly, mTLS authenticates the ends of a channel, but does not itself define whether service A can perform operation X on resource Y on behalf of user Z.

radio_button_unchecked 34.2 Logical principles and components

NIST SP 800-207 describes principles that can be applied directly to APIs: resources and services are treated as assets; all communication is protected regardless of location; access is granted per session and with least privilege; decisions consider identity, asset status, behavior and context; and the organization collects information to continually improve posture.

In NIST's logical architecture, the Policy Engine makes the decision to grant, deny, or revoke access. The Policy Administrator executes this decision, for example by configuring or terminating a session. The Policy Enforcement Point enables, monitors, and terminates the connection between the subject and the resource. On an API platform, the gateway, a mesh proxy, a sidecar or the backend itself can play the role of enforcement.

Authorization terminology used in software architectures often complements this model with PDP , PEP , PIP , and PAP . Policy Decision Point evaluates the policy; the Policy Information Point provides attributes; the Policy Administration Point administers policies; and the Policy Enforcement Point enforces the decision. Names vary between products, but responsibilities need to remain clear to avoid blind spots and conflicting decisions.

A decision can be binary, but advanced architectures also generate obligations: require step-up, mask fields, reduce transactional limit, activate reinforced logging, impose specific rate limit or forward the operation for approval. These obligations need to be supported by enforcement and audited as part of the outcome.

radio_button_unchecked 34.3 Protected resources, subjects and surfaces

Zero Trust starts by identifying the resources that truly need protection. In APIs, the resource is not just the hostname or the endpoint. It can be an operation, a record, a sensitive field, a dataset, a queue, a secret, a signing key, or an administrative function. The more precise the classification, the more granular the policy can be.

The subject also needs to be modeled correctly. The same request can carry the identity of the end user, the client application and the intermediate workload. In delegated flows, the backend needs to distinguish who is acting and on whose behalf. Losing this distinction produces generic tokens, incomplete logs, and excessive privileges.

The protected surface includes public interfaces, B2B integrations, internal APIs, administrative endpoints, messaging channels, and external dependencies. The inventory must list owner, processed data, authentication method, exposure, consumers, criticality and policies. Unknown, old, or test APIs are difficult to bring into a Zero Trust strategy because they have no risk context or governed lifecycle.

Data classification influences the decision. An authenticated consumer can receive basic fields but not full financial data. A workload authorized to read one record may not have permission to export thousands of records. The principle of least privilege needs to cover volume, purpose, time, context, and object properties.

Different identities participate in the same call

radio_button_unchecked 34.4 Decision by request and dynamic trust

In an API, the practical decision unit is typically the request or a short session associated with a limited set of operations. The gateway identifies the subject, validates the credential, extracts claims, queries attributes when necessary and evaluates the policy applicable to the method, path, resource and context. Authorization should not be inferred merely because a previous connection was accepted.

Dynamic confidence means that the outcome can change when the signals change. A user authenticated with MFA may lose access if the device is compromised, the location becomes incompatible, the token is revoked, or the session risk increases. In critical applications, sensitive actions may require re-authentication, additional proof, or out-of-band confirmation.

Continuous evaluation does not imply that each call depends on dozens of remote services. Policies can be compiled and distributed to local PDPs; attributes can have short TTLs; low-risk decisions can be cached; and revocation events can invalidate state. The challenge is to balance timeliness, availability, latency and security.

The design needs to specify behavior when signals are unavailable. A public query API may operate in a degraded fashion, while a high-value transfer must deny access if the PDP , anti-fraud service, or posture confirmation cannot be queried. Fail-open and fail-closed are decisions per class of operation, not global options.

radio_button_unchecked 34.5 Human identity, application, workload and device

Human identity is typically established by an identity provider with multi-factor authentication and risk policies. The resulting token must have an appropriate issuer, subject, audience, scopes, time and authentication level. Corporate groups are useful, but often too broad for fine-grained authorization; attributes of function, unit, relationship and context can complement the decision.

The client application is also a subject. In OAuth 2.0, the client_id identifies the registered software and the client type influences the available controls. Confidential clients authenticate to the token endpoint; Public customers depend on PKCE and environmental protection. In B2B integrations, the identity of the organization and partner system must be separated from the identity of the end user.

Workload identity avoids static credentials shared between services. Short-lived certificates, SPIFFE IDs, managed identities, and tokens designed for service accounts allow you to bind the call to the running instance or service. In Kubernetes, ServiceAccounts and identity federation with the cloud reduce the need for permanent secrets in Pods.

The device provides additional signals: logging, integrity, versioning, encryption, EDR posture, and compliance. These signals should not be confused with the user's identity. A valid person on an unmanaged device can be granted limited access; a valid workload on a compromised node may require quarantine. Mature policies combine the dimensions without transforming one of them into absolute trust.

radio_button_unchecked 34.6 Tokens, mTLS and proof of ownership

Bearer tokens are used by whoever owns them. If they are copied from compromised logs, memory, browser or channel, they can be reused until they expire or are revoked. Therefore, they need protected transport, secure storage, restricted audience, minimum scopes and short lifespan. Zero Trust does not eliminate bearer tokens, but it reduces their scope and assumes that leaks are possible.

Sender-constrained tokens bind token usage to a cryptographic key. In OAuth, mTLS can bind the token to the client certificate, while DPoP uses an application-level signed proof and binds the token to a public key. The resource server validates not only the token, but also the demonstration of possession of the corresponding key.

mTLS is especially suited to server-to-server integrations, workloads, and environments with operational PKI. DPoP can be used by clients who are unable to conveniently present TLS certificates. Both reduce the value of a stolen token, but do not prevent misuse by a compromised legitimate client nor do they replace authorization and replay protection of the operation itself.

In high-risk APIs, proof-of-possession must be combined with idempotence, message signing when necessary, specific audience and anomaly detection. Broad tokens, long duration, and indiscriminate propagation between microservices contradict least privilege, even if they are cryptographically linked.

radio_button_unchecked 34.7 Granular authorization and policy architecture

RBAC is useful for stable responsibilities, but is rarely sufficient alone for complex APIs. ABAC allows you to combine attributes of the subject, resource, action and environment. ReBAC represents relationships, such as principal, representative or member of an organization. Policies can combine these models as long as they remain understandable, testable, and auditable.

The architecture needs to define where the decision occurs. A gateway can query a central PDP , use local policy-as-code, or combine decisions. The backend remains responsible for rules that depend on the business state and for preventing direct access that bypasses the gateway. In a service mesh, authorization between workloads can occur in the proxy, while object authorization remains in the application.

PIPs provide directory attributes, CMDB, device inventory, data classifiers, risk, and context. The PAP manages policies and their lifecycle. For production, policies need versioning, review, unit testing, simulations with historical traffic, approval, gradual rollout and rollback.

The result of the decision must be explainable. Logs do not need to expose the entire policy, but should record decision identifier, policy version, subject, resource, action, result and main reason. This evidence is essential for auditing, troubleshooting and incident investigation.

Conceptual example of policy-as-code

package api.transferencias default allow := false allow if { input.subject.assurance >= 2 input.subject.tenant == input.resource.tenant "transfer:write" in input.token.scopes input.transaction.amount <= input.subject.daily_limit input.device.compliant == true }

radio_button_unchecked 34.8 API Gateways as enforcement points

API Gateway is a natural PEP for north-south traffic. It can terminate TLS, validate tokens, verify certificates, query PDPs, apply rate limits, remove external credentials, propagate controlled identity, and record decisions. Its central position facilitates consistency, but does not authorize turning the gateway into the sole security component.

The gateway must validate issuer, audience, signature, time, token type and mandatory claims. Generic policies based only on token presence generate a false sense of protection. The route must be associated with an explicit authorization policy, and administrative endpoints must have even more restrictive controls.

The identity propagated to the backend needs to be protected against spoofing. Internal headers must be removed from the external request and recreated by the gateway; the channel to the backend must be authenticated; and the service needs to accept these headers only from authorized sources. Alternatively, the gateway can exchange the token for a specific audience token or use workload credentials.

High availability requires evaluating gateway dependencies: introspection, JWKS, PDP , KPS, directories, and risk services. Caches must respect expiration, revocation and versioning. Metrics should separate authentication failures, policy denials, PDP unavailability, backend error, and threshold blocks.

radio_button_unchecked 34.9 Service mesh, Kubernetes and east-west traffic

Edge security does not prevent lateral movement if internal services trust any source on the network. A service mesh can provide automatic mTLS, workload identity , and L4/L7 authorization between services. Each call becomes associated with the workload identity , regardless of the ephemeral IP or the node on which the Pod is running.

In Kubernetes, identity can come from ServiceAccounts and be federated with cloud providers. Pods should not share long-lived static credentials. RBAC controls actions on the cluster's API, while mesh policies and NetworkPolicies control workload communications. These mechanisms act on different planes and need to be designed together.

The mesh policy can restrict which workloads call which service, port, method, or path. For authorization on behalf of the user, the proxy can evaluate propagated claims, but origin and integrity must be guaranteed. The backend remains necessary for decisions based on objects, balances, relationships or business state.

Gradual adoption should avoid the belief that permissive mode is an end state. First, the traffic would be inventoried; then, mTLS and identity are enabled; then explicit policies replace broad permissions. Telemetry helps detect hidden dependencies before blocking.

radio_button_unchecked 34.10 Microsegmentation , egress and data protection

Microsegmentation limits communication paths to reduce attack surface and impact radius. In APIs, segmentation can use workload identity , namespace, domain, sensitivity, and purpose, rather than relying solely on IP addresses. NetworkPolicies, mesh policies, firewalls and internal gateways can cooperate, as long as ownership and precedence are defined.

Controlled egress is an important part of the model. A compromised workload must not be able to access any Internet destination, cloud metadata, or internal service. Egress gateways, name and identity allowlists, controlled DNS, proxies, and monitoring help limit exfiltration and SSRF. Rules must consider resolution, redirects, private IPs, protocols and destination changes.

Zero Trust is resource and data driven. Encryption in transit and at rest is necessary, but policies also need to control minimization, masking, finalization, retention, and export. An API that returns unnecessary fields or allows unlimited pagination may violate least privilege even with strong authentication.

Secrets, keys, and certificates must have scope, rotation, and usage track. Access can be mediated by identity-aware proxies, secret stores and managed identities. Credentials shared between services prevent selective assignment and revocation, increasing the impact radius of a compromise.

radio_button_unchecked 34.11 Telemetry, risk and adaptive response

Adaptive decisions depend on reliable telemetry. IdP, gateway, mesh, endpoint, WAF, SIEM and application produce signals that may indicate anomaly: location changes, unusual volume, object enumeration, repeated failures, degraded device posture, new certificate or non-standard access. These signals need to be normalized, correlated, and evaluated with latency compatible with the use case.

The answer doesn't have to be just blocking. The architecture may require MFA, reduce scopes, rate limit, disable export, mark the session for review, or revoke credentials. The choice must consider the impact and reliability of the detector. Overly aggressive controls without feedback create unavailability and encourage permanent exceptions.

Zero Trust Observability needs to record decisions, not just traffic. Useful metrics include per-policy allow/deny ratio, PDP latency, cache hit, attributeless decisions, propagation failures, stale credential usage, mTLS coverage, uninventoried flows, and revocation time. Traces help identify which PEP or backend made the final decision.

Privacy and security of the signals themselves need to be considered. Authorization logs can contain identifiers, groups, risk, and context. Collection must be minimized, protected by access and retention, and never include full tokens, private keys, or unnecessary sensitive data.

Continuous scanning is not indiscriminate surveillance

Collection must be proportional, finalistic and protected. Zero Trust requires sufficient signals for decisions and investigation, but does not justify recording credentials, sensitive payloads or attributes without operational need.

radio_button_unchecked 34.12 Availability and failures of trust components

A Zero Trust architecture adds critical components to the path: IdP, JWKS, introspection, PDP , PIP , risk service, and certificate infrastructure. Each dependency needs SLO, redundancy, timeout, cache, fallback and runbook. A secure policy that makes all APIs unavailable due to simple failure is operationally incomplete.

Public key caching is usually secure when respecting rotation and identifiers. Decision caching is more delicate because attributes and risk can change. The cache must include subject, resource, action, relevant context, policy version, and TTL. Revocation events may invalidate decisions before expiration.

Fail-open may be acceptable for public or low-impact operations, as long as the degraded mode is explicit and monitored. Fail-closed is appropriate for financial, administrative or sensitive data operations. Between extremes, the organization may offer limited reading, freeze changes, or require an alternate channel.

Recovery needs to be tested. Certificate rotation, IdP unavailability, policy rollback, cache loss and issuer change are continuity scenarios. Controlled exercises show whether the team can distinguish legitimate denial from infrastructure failure.

radio_button_unchecked 34.13 Governance and maturity journey

Adopting Zero Trust is a journey of transformation, not a one-off project. A practical starting point is to inventory resources, identities, flows and policies; remove shared credentials; centralize identity; secure communications; make decisions explicit; and expand observability. The exact order depends on the organization's risk and capacity.

Maturity models help organize work into pillars. CISA Zero Trust Maturity Model 2.0 works with identity, devices, networks, applications and workloads, data, visibility/analytics, and automation/orchestration. For APIs, these pillars translate into strong identity, posture, microsegmentation , gateway policies, data protection, telemetry, and automatic response.

Exceptions need an owner, justification, scope, deadline and compensation. Policies and attributes must have catalogue, versioning and test evidence. Maturity metrics should measure coverage and results: percentage of inventoried APIs, restricted audience tokens, workloads without static credentials, mTLS traffic, explicit policies, revocation time and improper access incidents.

The strategy must avoid big bang. An observation mode identifies flows; policies are applied to controlled groups; denials are analyzed; and coverage grows per domain. Security results need to be combined with latency, availability and customer experience metrics.

Evolution of maturity: from isolated controls to adaptive decisions

radio_button_unchecked 34.14 Troubleshooting and investigation

A Zero Trust denial can be created in multiple layers: certificate, token, posture, policy, rate limit, mesh or business rule. Troubleshooting begins by identifying the PEP that responded, the decision_id and the stage of the failure. The consumer must receive a safe answer; details remain in protected logs.

In authentication, check certificate chain, issuer, audience, signature, time, nonce and binding. In authorization, compare subject, action, resource, context, provided attributes, and policy version. In mesh, confirm workload identity , mTLS mode and applied rule. In Kubernetes, validate ServiceAccount, labels, namespace, and NetworkPolicy.

Incorrect clocks, old caches, incomplete rotation, removed headers, wrong audiences, and missing attributes produce intermittent incidents. Distributed traces must preserve correlation without propagating tokens. When an external PDP participates, its latency and result must appear as span or event.

The investigation should avoid disabling broad controls as a first attempt. A temporary bypass needs to be minimal, approved, monitored and removed. Otherwise, the organization turns troubleshooting into creating security debt.

radio_button_unchecked 34.15 Case studies and labs

Case 1 - B2B integration: a partner uses OAuth Client Credentials with mTLS. The access token has a specific audience and minimum scopes; the gateway validates the certificate and token binding; the backend receives a controlled internal identity. The rotation occurs with overlapping certificates and telemetry identifies consumers still stuck with the old material.

Case 2 - microservices in Kubernetes: workloads receive short identities and communicate via service mesh with mTLS. Policies allow only necessary flows and NetworkPolicies limit network paths. End user identity is propagated in a verifiable form only where necessary; Object decisions remain in the domain service.

Case 3 - adaptive financial transaction: a common transfer is authorized with a valid MFA session, compliant device and daily limit. When the risk increases, the PDP requires step-up and reduces the maximum value. The result, signals, and policy version are audited without logging the token or full payload.

Suggested labs

1) Model subject, resource, action and context for three APIs. 2) Implement a deny-by-default policy in a test environment. 3) Compare bearer token and DPoP /mTLS. 4) Configure workload authorization in service mesh. 5) Simulate PDP unavailability and validate degraded mode. 6) Build a coverage, decisions and latency dashboard.

radio_button_unchecked Chapter summary

Zero Trust eliminates implicit trust based solely on network, ownership, or past authentication. Protection focuses on explicit resources and decisions. In APIs, this means identifying subjects, classifying data, validating credentials, evaluating context, applying authorization by action and object, and continuously observing the result.

API Gateways, service meshes and backends play complementary enforcement roles. mTLS authenticates peers; linked tokens reduce replay; RBAC, ABAC and ReBAC express policies; workload identity replaces static secrets; microsegmentation reduces lateral movement; and telemetry supports adaptive response. No single control implements Zero Trust.

The architecture needs to be available, governable and explainable. Policies, attributes and caches have a life cycle; critical dependencies require SLO and fallback; denials must be investigable; and adoption needs to advance gradually by risk and ownership. Maturity is measured by coverage and effective reduction of privilege and impact radius.

Next step of the course

The next chapter applies the fundamentals of APIs, identity, security and governance to the Open Finance and Open Banking Brasil ecosystem, in which federated trust, consent, certificates, security standards and high availability are central requirements.

radio_button_unchecked Zero Trust Checklist for APIs

• APIs, operations, data, owners and consumers are inventoried and classified.
• No network location is used as sufficient proof of authorization.
• User, client, workload and device are separate and correlatable identities.
• Tokens have a minimum audience, scope and useful life; static credentials are controlled exceptions.
• mTLS or DPoP is applied where the reduction in replay justifies the operational cost.
• Policies evaluate subject, action, resource and context and have deny-by-default when appropriate.
• PEPs are non-circumventable and backends maintain business and object authorization.
• Workloads use short identities; service mesh and NetworkPolicies reduce lateral movement.
• Egress, secrets, data, and exports are controlled by purpose and least privilege.
• Decisions, policy_id, version, latency, and reasons are observable without recording secrets.
• IdP, PDP , PIP , JWKS and PKI failures have degradation mode and runbook tested.
• The maturity journey has coverage, deadline, owner and exception removal metrics.

radio_button_unchecked Exercises

• Explain why a private network should not grant automatic authorization to an API.
• Map Policy Engine , Policy Administrator and PEP into a gateway and service mesh architecture.
• Differentiate user identity, application, workload and device in a single call.
• Compare bearer token, OAuth mTLS and DPoP from a replay and operation point of view.
• Design an ABAC policy for consulting and changing financial data.
• Define fail-open , fail-closed , and degraded behavior for three classes of operation.
• Propose microsegmentation and controlled egress for an API in Kubernetes.
• Describe which signals should be recorded to explain an access decision.
• Create a migration plan from static credentials to workload identity .
• Define Zero Trust maturity indicators for an enterprise API platform.

radio_button_unchecked Glossary

radio_button_unchecked Technical references

• NIST SP 800-207 - Zero Trust Architecture . 2020.
• NIST SP 800-207A - A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments. 2023.
• CISA - Zero Trust Maturity Model, Version 2.0. 2023.
• NIST SP 800-204B - Attribute-based Access Control for Microservices-based Applications Using a Service Mesh. 2021.
• NIST SP 800-204C - Implementation of DevSecOps for a Microservices-based Application with a Service Mesh. 2022.
• IETF RFC 6750 - OAuth 2.0 Bearer Token Usage.
• IETF RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound access tokens.
• IETF RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession at the Application Layer ( DPoP ).
• OpenID Foundation - OpenID Connect Core and related specifications.
• SPIFFE Project - SPIFFE and SPIRE specifications and documentation.
• Kubernetes Documentation - Service Accounts, RBAC, Network Policies and Pod Security.
• Istio Documentation - Security, PeerAuthentication and AuthorizationPolicy.

Update note

Zero Trust is an evolutionary strategy and depends on the product version, threat model and regulatory context. Before applying the examples, validate the official specifications, gateway, fabric, identity provider, and deployed platform support.