Managing gateway configurations at scale is harder than it looks. When a plugin needs to apply to most routes, but not all, teams could either duplicate configuration across routes and violate DRY (“Don’t Repeat Yourself”) principles, or write custom code to handle the exceptions. Neither scales well, and both create long-term maintenance debt.

With conditional plugin execution, users can now attach conditional expressions directly to any plugin, based on request attributes like headers, paths, or content types. The gateway evaluates these expressions in real-time and decides whether to run the plugin or bypass it entirely.

This means you can apply a single plugin broadly and let the expression handle the exceptions, keeping your configuration. Whether you're enforcing auth policies that shouldn't fire for internal traffic, scoping transformations to specific content types, or preventing a validation plugin from running in the wrong context, conditional execution gives you the granular control to do it right.

In 3.14 we’re adding this feature as a Beta release. Read more about how conditional plugin execution works and what you can do with it in [this blog](https://konghq.com/blog/engineering/conditional-policy-execution)this blog and [our documentation](https://developer.konghq.com/gateway/configure-conditional-plugin-execution/)our documentation.

Kong has long supported a number of out-of-the-box plugins for both validating and generating JWT tokens, as well as using those tokens to authenticate callers.

But sometimes JWT validation can get complicated. Routing based on claims, supporting multiple identity providers, conditional logic based on headers — these are common requirements that can be hard to accomplish with a standard plugin. Kong Gateway 3.14 adds native JWT nodes to the Datakit plugin, letting you incorporate JWT operations directly into your Datakit visual workflow alongside transformations, routing logic, and other orchestration steps. 

Three nodes cover the full range of JWT use cases:

• - **JWT Decode** — Parse a JWT and extract header and payload data without verifying the signature. Useful for reading claims early in a workflow to inform downstream decisions.
• - **JWT Verify** — Verify a token's signature and validate its claims, including JWKS-based validation for tokens issued by external identity providers.
• - **JWT Sign** — Create a new signed JWT for forwarding to upstream services, enabling the gateway to act as a token issuer in service-to-service flows.

Together, these nodes simplify realizing complex authentication patterns as part of Datakit flows. You can validate an incoming JWT against a JWKS endpoint, authenticate the consumer, and re-sign a new token for the upstream service — all within a single visual workflow. Multi-IdP routing becomes composable too: decode the token first, inspect the issuer claim, and branch the workflow accordingly. The result is complex auth logic that lives at the gateway and requires no code to maintain.

Without native authentication support for WebSockets, teams often rely on workarounds — such as decoupling authentication from WebSocket message processing or handling authentication outside the WebSocket connection. In practice, these approaches introduce architectural complexity, are difficult to audit, and can lead to inconsistent enforcement of security policies across real-time workloads.

Kong Gateway 3.14 addresses this with native OIDC and mTLS authentication, plus ACL support, are now enforced at the WebSocket handshake — before a persistent connection is ever established. This enables a consistent authentication and authorization model across both HTTP and WebSocket traffic.

Additionally, new WebSocket metrics give platform and operations teams real-time visibility into **active connections, disconnects, handshakes per minute, and handshake failures per minute**. These insights help teams monitor load, detect issues, and operate WebSocket workloads more effectively.

Together, these capabilities eliminate the need for authentication workarounds, reduce architectural complexity, and provide the **security, consistency, and visibility** required to run WebSocket workloads — including real-time and AI-driven applications — with confidence at enterprise scale.

When an API Gateway receives an inbound request carrying a user's access token, it needs to call multiple downstream microservices, but forwarding that same token to every service is both a security risk and a scoping problem, since the token was issued for the gateway, not for each individual backend. This can result in an over-privileged service or leaking a broadly-scoped token deep into the backend.

Kong Gateway 3.14 adds native support for OAuth 2.0 Token Exchange (RFC 8693) within the OIDC plugin, bringing a standards-based solution to this problem at the gateway layer. Token exchange allows the gateway to accept a token in one format or scope, validate it, and issue a new token tailored for the downstream service, all without touching upstream service code or maintaining custom middleware. Credentials stay out of application logic, rotation happens centrally, and every exchange is governed by the same policy layer as the rest of your API traffic.

For teams building microservices, multi-tenant platforms, or federated architectures, this means token transformation, scoping, and delegation become gateway-level concerns: consistent, auditable, and free from the fragility of service-to-service credential management.

To learn more about token exchange in Kong API Gateway, please read [this blog](https://konghq.com/blog/engineering/token-exchange-at-the-gateway)this blog.

Over Kong Gateway 3.13 and 3.14, we’ve introduced a unified approach to cloud-native, IAM-based authentication across AWS, Azure, and GCP, effectively eliminating the need for static credentials. This update allows Kong to connect securely to essential components like Postgres databases, Redis caches, and HashiCorp Vault using the native identity systems of each cloud provider. By moving away from static access keys and passwords, enterprise security teams can achieve a consistent security posture across their entire infrastructure, ensuring that service-to-service connections are governed by the same identity models as the rest of their cloud environment.

To learn more about cloud-native authentication in Kong API Gateway, please read [this blog](https://konghq.com/blog/engineering/cloud-native-authentication)this blog.

As usage-based pricing becomes the standard model for APIs and AI services, platform teams need metering infrastructure that's accurate, flexible, and decoupled from their analytics stack. Bolting consumption tracking onto existing observability pipelines creates coupling that's hard to unwind — and it rarely gives billing systems the granular, request-level data they need.

The new Metering & Billing plugin for Kong Konnect brings real-time metering policies directly to the gateway. Teams can filter which requests get metered via plugin configuration, and define the metering subject and data payload using request headers or query parameters — giving you precise control over what gets tracked and how it maps to a billable event. Whether you're metering API calls by consumer, tracking token consumption for AI traffic, or scoping usage by tenant, the plugin provides the policy definitions needed to feed OpenMeter with clean, structured data at the source.

The result is a metering layer that lives where your traffic already flows — no custom middleware, no pipeline dependencies, and no post-processing to reconstruct what happened.

The less time your team spends writing glue code, the more time it has to build the platform your developers actually rely on.

Ready to get started? Upgrade to Kong Gateway 3.14 and see what's new in [the changelog](https://developer.konghq.com/gateway/changelog/)the changelog. If you want to see these features in action, [request a demo](https://konghq.com/contact-sales)request a demo or try them hands-on in Kong Konnect today.