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.

In this demo, I use Docker to create a container for Kong and another for a Spring Boot app that understands the x-userinfo HTTP header.

The slides used in the screencast can be found on GitHub.