Kong Gateway 3.14 shifts policy and identity control to the gateway

At a glance

What this is: Kong Gateway 3.14 shifts multiple identity and policy functions into the gateway, including conditional execution, token exchange, WebSocket authentication, and cloud-native IAM.

Why it matters: It matters because IAM, API security, and platform teams can enforce identity decisions closer to traffic, reducing custom code and making policy drift easier to govern across APIs and AI workloads.

Context

Kong Gateway 3.14 is a product release focused on moving security and identity decisions into the gateway layer. The article says platform teams are struggling with policy logic that does not fit a one-size-fits-all model, especially as services, credentials, and cloud providers multiply.

The governance problem is broader than API routing. When token scoping, cloud-native authentication, and handshake-time enforcement are handled downstream, teams end up with inconsistent controls and maintenance-heavy glue code. This release is framed around pushing those decisions to the point where traffic is already being evaluated.

For IAM practitioners, the key question is whether the gateway becomes a control plane for identity enforcement or just another place where policy fragments accumulate. The article argues for the former by placing conditional execution, token exchange, and cloud-native authentication in one policy layer.

Key questions

Q: How should teams stop token reuse across downstream services at the gateway?

A: Use the gateway to validate the inbound token, exchange it for a downstream token with narrower scope, and avoid passing the original credential into every backend. That keeps delegation explicit, reduces over-privileged service access, and makes policy decisions easier to audit across service-to-service flows.

Q: Why do gateway-level identity controls reduce policy drift in API platforms?

A: Because the enforcement decision sits closer to the request path, the same policy can govern more traffic paths without being duplicated in application code. That reduces exception handling, makes scoping decisions more consistent, and gives platform teams one place to review how identity-related controls are applied.

Q: What breaks when WebSocket authentication is handled after connection setup?

A: You lose a clean control point for consistent authentication and authorisation, because the session already exists and may be difficult to re-evaluate safely. That creates audit gaps, inconsistent enforcement, and more reliance on workarounds that separate identity from connection governance.

Q: Should platform teams move more IAM logic into the gateway?

A: Yes, when the logic is about request scoping, token delegation, or traffic-specific enforcement that application services should not each recreate. The gateway is the right boundary for those decisions when the goal is consistent policy, lower code complexity, and clearer operational ownership.

How it works in practice

Conditional plugin execution for request-scoped policy

Conditional plugin execution lets a gateway decide at runtime whether a plugin should run based on request attributes such as headers, paths, or content types. That changes gateway policy from static attachment to context-aware enforcement. Instead of duplicating routes or writing custom exception logic, teams can express when a control applies and when it should be bypassed. This matters for identity and security because enforcement is often only correct in some traffic contexts, not all. Practical implication: treat conditional policy as a way to reduce configuration sprawl while preserving precise control boundaries.

Practical implication: use request attributes to scope policy where identity or validation rules should not apply universally.

Native token exchange and JWT handling at the gateway

JWT decode, verify, and sign operations at the gateway let identity decisions happen before traffic reaches upstream services. Native OAuth 2.0 Token Exchange means the gateway can accept one token, validate it, and issue a new token for a downstream service with narrower scope. That reduces the need to forward the original caller token everywhere and avoids over-privileged service access. The important design point is that the gateway becomes the place where token transformation and delegation are governed, not an application-level afterthought. Practical implication: move scoping and delegation logic out of service code and into gateway policy.

Practical implication: issue downstream tokens with service-specific scope instead of reusing the original caller token across backends.

WebSocket authentication before persistent connections exist

WebSocket traffic creates a different identity problem because authentication happens before a long-lived connection is established, not on each message by default. Kong Gateway 3.14 places OIDC, mTLS, and ACL checks at the handshake stage, which aligns authorization with connection creation rather than message processing. That gives platform teams a consistent model across HTTP and real-time workloads, and it improves visibility into connection health and failure rates. Practical implication: enforce identity at handshake time if you need auditable control over persistent real-time channels.

Practical implication: authenticate and authorize WebSocket sessions at handshake time, not after the channel is already open.

NHI Mgmt Group analysis

Gateway-level identity control is becoming a governance boundary, not just an implementation convenience. Kong Gateway 3.14 is interesting because it moves scoping, delegation, and enforcement into the traffic layer where decisions can be made consistently. That shift matters to identity teams because policy drift usually appears when control lives too far from the request path. Practitioners should read this as evidence that the gateway is now part of the IAM control surface.

Token reuse across services is the identity weakness this release is trying to contain. Forwarding a caller token unchanged to multiple downstream services creates scope leakage, even when the original authentication was valid. Native token exchange changes the governance model by making the gateway the place where delegation is narrowed and reissued. That aligns with least privilege in distributed systems, where service scope should not inherit the caller's entire authority.

WebSocket authentication exposes an edge-control gap that traditional request-by-request IAM does not close. Long-lived connections need enforcement at establishment time because there may be no later opportunity to re-evaluate identity in the same way as HTTP traffic. This is a practical reminder that real-time workloads need policy and observability at connection formation, not only at application access. Teams running persistent channels should treat handshake-time control as a first-class governance requirement.

Cloud-native authentication is replacing static credential assumptions in multi-cloud architectures. The article's move toward AWS, Azure, and GCP identity systems reflects a broader shift from stored secrets to platform-issued trust. That reduces one class of operational fragility, but it also raises the bar for identity consistency across providers and services. The practitioner takeaway is that distributed infrastructure now needs a common authorization model even when the underlying cloud primitives differ.

Policy complexity is moving from code into configuration, which changes where identity review must happen. Conditional execution and gateway-native identity features reduce glue code, but they also concentrate more consequential control logic in fewer places. That creates a named governance pressure we would call edge policy concentration: when the gateway becomes the primary enforcement point, misconfiguration has broader blast radius. Teams should review gateway policy with the same scrutiny they would apply to IAM logic in application code.

What this signals

Edge policy concentration: When token exchange, conditional execution, and authentication checks all sit in one gateway layer, governance quality depends on the consistency of that layer more than on scattered application logic. That makes gateway policy review a first-order identity control, not a deployment detail.

Gateway-native scoping also changes how teams should think about multi-cloud identity. If AWS, Azure, and GCP authentication are normalized at the edge, then the practical challenge becomes policy consistency across cloud-native identities rather than local credential handling inside each service.

For platform teams, the operational signal is simple: if the gateway is now issuing, transforming, and constraining identity-bearing tokens, then identity governance has moved closer to runtime traffic decisions and away from downstream application code.

For practitioners

• Audit gateway policy for scope leakage Review where a single caller token is still being forwarded to multiple downstream services. Replace broad token reuse with gateway-mediated delegation that narrows scope per backend and keeps credentials out of application code.
• Scope conditional policy to the correct traffic class Map every plugin that should not run universally and express its exception logic through request attributes such as headers, paths, or content types. This avoids duplicated routes and prevents policy from firing in the wrong context.
• Move WebSocket identity checks to handshake time Require OIDC, mTLS, or ACL enforcement before the connection is established so real-time sessions are governed consistently. Track handshake failures and connection health as part of the operational control set.

Key takeaways

• Kong Gateway 3.14 moves several identity and policy decisions into the gateway so teams can govern traffic closer to where it is enforced.
• The article shows how token scoping, WebSocket authentication, and cloud-native IAM become harder to manage when they remain scattered across service code.
• The practical implication is to treat the gateway as part of the identity control plane and review its policy surface with the same discipline as IAM logic.

Key terms

• Conditional Plugin Execution: A gateway policy pattern where a plugin runs only when request attributes match defined conditions. It reduces duplicated configuration and lets teams scope enforcement to the traffic that actually needs it, rather than applying controls universally and then compensating with exceptions.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• WebSocket Handshake: A WebSocket handshake is the initial HTTP upgrade exchange that establishes a persistent WebSocket session. It is the point where authentication, origin validation, and connection acceptance decisions are made. After the upgrade, the channel becomes a long-lived TCP connection that behaves differently from standard HTTP requests.
• Edge Policy Concentration: A governance condition where more identity and security decisions are enforced in one gateway layer instead of across distributed application code. It improves consistency, but it also makes configuration quality and review discipline more important because one control surface now carries more authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.