Zero Trust security model principle
Zero Trust is a security model that assumes all users, devices, and networks are untrusted and must be verified before access is granted, even if inside the organization's network. All requests for access must be authenticated and authorized before being granted. Organizations must continuously monitor and audit user activity to ensure access is only granted to those who need it. This model reduces data breach risk by ensuring only authorized users access sensitive data.
External Identity Propagation pattern definition
In External Identity Propagation, the edge component forwards externally received authentication data (access token, ID token, session cookie, or certificate) directly to internal services without transformation. Internal services are responsible for verification of the received authentication data, extracting identity context (user ID, attributes), and making access control decisions. When an internal service communicates with another service, it forwards the authentication data further downstream. Verification may require contacting a Verifier such as an authorization server or OCSP responder.
External Identity Propagation cons
Cons of External Identity Propagation: tight coupling to external protocols (each microservice must understand multiple types of external authentication data and formats like OAuth2, OIDC, cookies, requiring protocol-specific logic); increased security risk if external authentication data is leaked and internal services are exposed; unsuitable for Zero Trust or multi-tenant environments; privacy concern because externally visible authentication data reused internally may expose identifiers intended for internal use, violating privacy requirements by enabling cross-context linkability and conflicting with GDPR and CCPA.
Simple Service-Level Identity Forwarding pattern definition
In Simple Service-Level Identity Forwarding, the edge component forwards externally received authentication data to internal services, but each microservice no longer forwards this data unchanged. Instead, a microservice extracts relevant identity information (user ID, roles, scopes) from the incoming request and creates a simplified representation of identity, such as a plain JSON object, self-signed JWT, or single value embedded in query or path parameter, when making calls to downstream services. This internal identity representation is not strongly cryptographically protected and relies on implicit trust between services, requiring downstream services to trust the integrity and correctness of identity information forwarded by upstream callers.
Simple Service-Level Identity Forwarding cons
Cons of Simple Service-Level Identity Forwarding: high trust requirement (downstream services must trust upstream callers to provide unaltered and accurate identity information); vulnerable to spoofing due to lack of cryptographic protection; unsuitable for Zero Trust or multi-tenant environments; protocol complexity leakage if any internal service becomes externally exposed; privacy concern from reusing externally visible authentication data internally, enabling cross-context linkability and conflicting with GDPR and CCPA. This pattern introduces risks commonly associated with Insecure Direct Object References (IDOR) resulting in data exposure.
Token Exchange-Based Identity Propagation pattern definition
In Token Exchange-Based Identity Propagation, a microservice receiving a request with externally issued identity (access token) exchanges it for a new, signed access token issued by an authorization server, using OAuth2 Token Exchange or OAuth2 Transaction Tokens protocol. This exchanged token is specifically scoped for a downstream internal service and propagated as part of the internal call. A Secure Token Service (STS) issues the new token; the STS may be implemented by the same authorization server as the Verifier or separately. Downstream services trust the token issued by the STS rather than the one used by the external client.
Token Exchange-Based Identity Propagation pros
Pros of Token Exchange-Based Identity Propagation: improved trust model because downstream services only need to trust the STS, not upstream service implementations; cryptographically verifiable identity because issued tokens are signed by an STS, offering strong integrity guarantees; scoping and audience control because exchanged tokens can be restricted in scope and audience, reducing token misuse risk.
Token Exchange-Based Identity Propagation cons
Cons of Token Exchange-Based Identity Propagation: OAuth2-specific, relying on OAuth2 Token Exchange or OAuth2 Transaction Tokens draft, limiting applicability to systems using that protocol family for externally visible authentication data; service-side complexity because application code must integrate with the STS to handle token exchange logic and manage caching or retries; latency overhead from token exchange process introducing additional network round-trips per request flow unless aggressively optimized; operational dependency on STS implementation availability and scalability.
Protocol-Agnostic Identity Propagation pattern definition
In Protocol-Agnostic Identity Propagation, the external request is authenticated at the system edge by a trusted component, which generates a cryptographically signed (and/or encrypted) data structure representing the external entity's identities and attributes (user ID, roles, permissions), typically a self-contained verifiable structure like a JWT or proprietary signed format. The edge component assumes the role of a Secure Token Service (STS). This signed identity structure is propagated downstream to internal microservices. Internal services trust the signature from the edge issuer and use the token to make access control decisions. Edge component roles (Edge Proxy, STS, Verifier) may be implemented in a single component or split across multiple cooperating services.
Protocol-Agnostic Identity Propagation pros
Pros of Protocol-Agnostic Identity Propagation: cryptographic trust from signed tokens providing strong guarantees about integrity and authenticity of propagated identity; decoupling from external authentication data because internal services neither handle external protocols nor differentiate whether requests originate from first- or third-party actors, simplifying their logic and trust assumptions; rich identity context by allowing inclusion of fine-grained identity and authorization metadata; secure across trust boundaries, suitable for multi-tenant and Zero Trust environments; separation of external and internal identities by enabling mapping of externally known identifiers to distinct internal representations, preventing direct exposure of internal identifiers and enhancing privacy by reducing correlation and tracking risks across domains.
Protocol-Agnostic Identity Propagation cons
Cons of Protocol-Agnostic Identity Propagation: key management complexity requiring secure handling and rotation of signing keys to maintain trust; token size overhead from signed tokens issued by edge component being large, increasing network overhead; revocation challenges because once issued, tokens may be valid for many services until expiration, complicating immediate revocation (mitigated by issuing short-lived tokens and tailoring subject structures to individual downstream services); increased complexity at the edge because the edge component must handle external authentication data verification as well as internal token generation and signing, making it a critical security component.
Identity propagation pattern spectrum
Identity propagation patterns exist along a spectrum. At one end, some patterns directly forward externally issued authentication data (OAuth2 tokens, session cookies, certificates) downstream, requiring internal services to understand and process original authentication protocols, increasing internal service complexity and trust assumptions. At the other end, a trusted system component at the edge transforms incoming authentication data into cryptographically signed, normalized identity structures, abstracting away the original protocol and data format, allowing internal services to remain agnostic to how authentication was performed. Between these extremes exist intermediate patterns where internal services rely on simplified identity representations issued or transformed by upstream services but without cryptographic protections.
Protocol-agnostic versus token-agnostic identity propagation definition
Protocol-agnostic or token-agnostic identity propagation means internal services consume a normalized, unified identity representation that abstracts away the details of the original authentication protocol and authentication data (including both primary credentials and authentication proofs). This abstraction enables internal services to remain stable, simplified, and focused on authorization logic, even as external authentication methods evolve or change.
Privacy concerns in identity propagation patterns
Privacy concerns particularly around cross-context linkability and risk of exposing internal identifiers affect all identity propagation patterns, though severity depends on how externally received authentication data is handled. Patterns like External Identity Propagation and Simple Service-Level Identity Forwarding directly reuse externally visible authentication data within the system, increasing risk that internal identifiers (such as subject claims in JWTs) become externally observable, enabling correlation of user activity across contexts. This undermines privacy goals like pseudonymisation and data minimisation and conflicts with integrity and confidentiality principles central to privacy-by-design thinking. Patterns like Token Exchange-Based Identity Propagation and Protocol-Agnostic Identity Propagation help enforce privacy boundaries by transforming or isolating authentication data before internal use.
Privacy-by-design techniques in identity propagation
Patterns like Token Exchange-Based Identity Propagation and Protocol-Agnostic Identity Propagation make it easier to adopt privacy-by-design techniques such as opaque tokens, session-referencing cookies, or identifier mapping, which reduce unnecessary exposure of user-specific identifiers. Even mapped identifiers can still reveal the existence of a persistent relationship with the system, which may be problematic in certain contexts. These patterns align well with legal requirements such as GDPR (Art. 5(1)(b, c, f), Art. 25, Art. 32, Recitals 26 and 30), CCPA, and similar frameworks.
Identity propagation and Zero Trust architecture alignment
Identity propagation patterns align with Zero Trust principles, which emphasize strict access control and continuous verification. Trustworthy identity propagation is essential for maintaining strong trust boundaries across a system. Protocol-Agnostic Identity Propagation and Token Exchange-Based Identity Propagation patterns are suitable for Zero Trust environments because they provide cryptographic verification and strong integrity guarantees. External Identity Propagation and Simple Service-Level Identity Forwarding are unsuitable for Zero Trust because their trust assumptions and lack of verifiability conflict with Zero Trust security guarantees.
Netflix Token Agnostic Identity Propagation reference
Netflix refers to the Protocol-Agnostic Identity Propagation pattern as 'Token Agnostic Identity Propagation' in a blog post on edge authentication and token-agnostic identity propagation.