Kong’s router runs before authentication, so it can’t directly route traffic based on who is making a request.
This guide shows you how to solve that using two plugins working together in the access phase:
-
OpenID Connect validates the bearer token and extracts a claim value (such as
client_id) onto a virtual credential. - Datakit reads that credential and maps its value to a named Upstream entity, overriding the backend for that specific request.
All callers share one Route and one Service. After authentication, the backend is selected dynamically based on the client’s identity.
This guide uses named Upstream entities, which preserves load balancing, health checks, and retries.
If you don’t need those features and prefer to route directly to a host:port without a pool, see Route requests to different targets based on the authenticated caller.
Note: The OpenID Connect plugin has a higher static priority than Datakit, so it always runs first in the
accessphase. No explicit plugin ordering configuration is required.