For an updated version of this blog post, see Use Kong Gateway to Centralize Authentication.
NOTE: The video and code in this post has just been updated for 2021!
A customer once asked me: “Hey – Can Okta integrate with Kong?” My first thought was: “What’s Kong?” A Google result later, I was introduced to the Kong API Gateway – an open-source API Gateway and Microservices management layer.
Spoiler alert: You totally can integrate Kong with Okta using its OpenID Connect plugin.
Still stuck wondering what an API gateway even is? Here’s a metaphor that works for me: You know that sci-fi movie trope in which you have a centralized hub that “jumps” you to other places in the galaxy? In that kind of system all the screening and security happens at the hub. It’s the same with Kong (and other API gateways).
In the case of the OIDC plugin, only Kong speaks directly to Okta using the Authorization Code flow. It then passes the contents of the ID Token to an internal service using an HTTP header called
x-userinfo. Your app just needs to know what to do with this HTTP header. It doesn’t have to do anything with OIDC itself.
This is easier to understand with some diagrams. Here’s what an architecture might look like without an API Gateway:
While you may have a load balancer sitting in front of everything acting as a “traffic cop”, each of your services has to know how to “speak” OIDC.
Here’s another diagram with an API Gateway in the mix:
In this case, only the Kong API gateway is interacting with Okta. Kong then passes the
x-userinfo header along after the user authenticates. This enables your services to be a lot leaner – no OIDC stack needed.
I created a screencast based on this working example.
The slides used in the screencast can be found on GitHub.
- Mar 25, 2021: Updated with refreshed video and new GitHub repo reference. Changes to this article can be viewed in oktadeveloper/okta-blog#570.