Topic starter
24/06/2026 7:24 pm
TL;DR: Conditional policy execution, native token exchange, WebSocket authentication, and cloud-native IAM are pushed into the gateway layer by Kong Gateway 3.14, reducing glue code while tightening control over API and AI traffic, according to Kong. The shift matters because identity, scoping, and enforcement move closer to traffic decisions, where IAM teams can actually govern them.
Editorial analysis by NHI Mgmt Group, based on content published by Kong: “Kong Gateway 3.14: More Control, Less Toil With Simplified Security and Policies”.
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.
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.
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.
Practitioner guidance
- Audit gateway policy for scope leakage Review where a single caller token is still being forwarded to multiple downstream services.
- 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.
- 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.
Bottom line: Kong Gateway 3.14 moves several identity and policy decisions into the gateway so teams can govern traffic closer to where it is enforced.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:40 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Kong Gateway 3.14 shifts policy and identity control to the gateway