API Authentication Explained(Part 3): API Gateway Architecture & Trust Boundaries
Understand trust boundaries, phantom tokens, and secure API architecture patterns for enforcing zero trust in distributed systems.
A system can use OAuth. It can issue signed tokens. It can even validate them correctly.
And still get breached.
Why?
Because security doesn’t fail at authentication — it fails at trust boundaries.
Modern API systems are distributed. Requests move across multiple services, networks, and domains. If trust is assumed rather than enforced at each boundary, attackers only need to breach one layer to move freely.
This is where architecture matters.
What Are Trust Boundaries in API Systems?
A trust boundary is any point where data crosses from one system to another, control shifts between components and trust assumptions must be re-evaluated
In other words:
A trust boundary is where you must stop and ask: “Should I trust this request?”
Common Trust Boundaries
In a typical API architecture:
Internet → API Gateway
Gateway → Internal APIs
Service → Service (microservices)
Organisation → Third-party APIs
Each boundary introduces risk.
Why Trust Boundaries Matter
Most API security failures happen when systems assume:
“This request is already authenticated, so it’s safe.”
That assumption leads to over-trusting internal traffic, reusing tokens across services, skipping authorisation checks, and even accepting tokens intended for other services. Attackers exploit these assumptions.
The Role of API Gateways in Trust Enforcement
The API Gateway sits at the first major trust boundary, right between untrusted external traffic and trusted internal systems.
At this boundary, the gateway should validate incoming tokens, enforce high-level access control, filter malicious or malformed requests and prevent direct access to internal services.
The gateway should not make final authorisation decisions, assume downstream services are safe, or even replace API-level validation.
It is a gatekeeper, not the final authority.
External vs Internal Trust
One of the biggest mistakes in API design is treating internal traffic as trusted.
External tokens (Tokens coming from clients) are exposed to the internet, can be intercepted or replayed, and may be malformed or malicious. These should never be trusted internally without transformation or validation.
Internal Tokens (used between services) should be controlled, scoped for internal use, and follow strict validation rules. This separation is critical.
The Phantom Token Pattern
To enforce this separation, many systems use the phantom token architecture. The problem it solves: "External tokens are not suitable for internal trust."
How Phantom Token Flow Works
Client sends an opaque token
API Gateway receives the request
Gateway validates the token with the auth server
Auth server returns a JWT (internal representation)
Gateway forwards the JWT to internal services
This approach is powerful because it ensures external tokens are never exposed to internal systems, reducing the risk of untrusted input spreading across the system, while internal services receive structured, validated identity data that is easier to enforce and reason about. It also helps clearly define and enforce trust boundaries, preventing accidental over-trust between components, and enables consistent logging and auditing, since all internal requests follow a standardised identity format that can be tracked and analysed reliably.
Token Transformation Across Services
In distributed systems, one service often calls another. This creates a new trust boundary. But this introduces a great risk.
If Service A simply forwards the original token to Service B:
Service B may receive more permissions than needed
Scope misuse can occur
Privilege escalation becomes possible
To solve this, systems use token exchange(RFC 8693). This allows a service to request a new token for downstream calls, reduce permissions (scopes), change the audience and even modify claims.
A good example is a User calls Service A with full permissions. Service A then calls Service B. Instead of forwarding the original token that was created from the user's request, Service A exchanges it for a restricted token.
As a result, Service B receives only the permissions it needs and a token specifically meant for it. This enforces least privilege across services.
Never trust any request — verify every time.
What this means for APIs is that every request must be authenticated, validated and authorised, even if it comes from another internal service, the API gateway or a trusted network.
Identity Propagation Across Services
When requests move across services, identity must move with them.
But this must be done carefully. Some common approaches include:
1. Token Reuse: Here, the same token is being used across various services. It is simple but quite risky.
2. Token Exchange: A new token will be issued per service. This is a more secure approach and is commonly used.
3. Embedded Tokens: Tokens contain nested tokens for downstream services. This method is complex but offers controlled access.
API Architecture Mistakes
A common mistake in API architecture is trusting internal traffic by default. Many systems assume that once a request is inside the network, it is safe, but this assumption breaks down in modern distributed environments. Attackers who gain access to one service can move laterally if no additional checks are in place. Closely related is the issue of blurring trust boundaries, where systems fail to distinguish between external identity (from clients) and internal identity (between services). Without a clear separation, external tokens may be trusted internally, weakening the overall security model.
Another major issue is the reuse of tokens across services without restriction. When a token is passed between services, it often carries more permissions than necessary, creating opportunities for privilege escalation. Instead of blindly forwarding tokens, systems should issue scoped or exchanged tokens tailored for each service. Additionally, many architectures make the mistake of ignoring audience restrictions and accepting tokens that were never intended for that service. This breaks the trust model and allows unintended access across different parts of the system.
There is also a tendency toward over-centralising security at the API gateway. While gateways are essential for enforcing entry-point controls, relying solely on them creates a dangerous gap. If a request passes through the gateway, downstream services may trust it without additional validation. Strong security requires layered enforcement, where both the gateway and individual services independently validate and authorise requests.
Real-World Impact
These architectural mistakes often result in serious security failures, including broken access control, where users can perform actions beyond their intended permissions, and cross-service data exposure, where sensitive data leaks between services that should be isolated. They can also lead to IDOR-style vulnerabilities in APIs, where attackers access resources belonging to other users, as well as unauthorised actions across systems, where one compromised component can trigger unintended operations elsewhere. All of this can occur even when OAuth is correctly implemented, showing that authentication alone does not guarantee security.
What’s Next
In Part 4, we will look at the most critical layer: fine-grained authorisation. It focuses on properly designing scopes and claims to prevent access control flaws such as IDOR in APIs, and on building secure, scalable authorisation systems.
