Topic starter
24/06/2026 7:24 pm
TL;DR: Conditional policy execution, token exchange, WebSocket authentication, and cloud-native IAM move into the gateway layer, according to Kong. Gateway policy now sits closer to traffic decisions, so identity and scoping can be enforced with less duplicated code.
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: 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.
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.
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.
Glossary terms: Conditional Plugin Execution, Token Exchange, WebSocket Handshake, Edge Policy Concentration
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 hours ago by NHI Mgmt Group
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: Gateway policy and identity move closer to traffic decisions
This post was modified 2 hours ago by NHI Mgmt Group