Centralize Authentication With Kong Gateway and OIDC
Let's take a look at a sample architecture and a demo of how Kong Gateway and OIDC can help simplify and centralize your authentication process.
Kong is an open-source API Gateway and microservices management layer that you can integrate with Okta using its OpenID Connect plugin. Why might you need an API Gateway like Kong? Well, you're probably trying to easily add services on top of all your APIs, for example, logging, authentication, or rate limiting. Kong's OIDC plugin ensures that it's only speaking 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. You can easily set the Kong OIDC plugin up to work with any IdP, in this tutorial we'll use Okta. This project is easier to understand visually. 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 Speaker Deck.
Use Kong Gateway to Centralize Authentication was originally published on the Okta developer blog on December 4, 2017.
Published at DZone with permission of Micah Silverman. See the original article here.
Opinions expressed by DZone contributors are their own.