Use Kong Gateway to Centralize Authentication

Use Kong Gateway to Centralize Authentication

You know that sci-fi movie trope in which you have a centralized hub that jumps you to other places in the galaxy? It’s the same with Kong (and other API gateways).

Aaron Miller

Outstanding work Micah. Really useful to understand how Okta and Kong interoperate and handy to have a local setup to fiddle with to understand how things fit together.

Micah

Thanks! Let me know if you have any questions.

Ashish Jain

Hi Micah, apart from integrating with Kong (or even Tyk), do you think, there is need for proper java based api gateway solution? (Which is open sourced, extensible and comes with basic admin UI.). Could be spring framework based.

Micah

Define “proper”. :wink: I’m not so sure. NGINX (which Kong runs in) is well suited for super fast scalable http connections and it (or Apache) often sit in front of Spring apps.

Mandar Kulkarni

Hi,

Thanks for the article, it helped a lot.

Few questions :

1) How did you land up on the page with Okta Login Widget when you were accessing the application (localhost:8000) as an unauthenticated user ?
Is that a feature of kong OIDC plug-in ?

I will appreciate if you can explain what happens behind the scene when a user clicks on the Login button of the Okta Widget.
For example, how can I use my application specific login page, passing username/password to Okta for verification and get an Id_token(or access token) for the successfully authenticated user.

2) In your screencast, you created users in Okta probably using some kind of management console.
Does it mean that all users of an application should have a corresponding Okta user ?
IMHO, OIDC does not provide any standardized endpoint that allows user registration flowing into the user datastore owned by the OpenID provider.

Micah

The login page I land on is the Okta-hosted login page. Kong automatically redirects to this page based on the configuration I provided. It’s not the signin-widget local to Kong or anything like that.

Okta is the Authorization Server and is the identity management solution. So, yes - all the users (and their credentials) live on Okta. This is the benefit of not having to roll your own security. Okta is responsible for properly storing user passwords, for instance. As a developer I don’t have to (and don’t want to) worry about that.

مازیار

Thanks for the great article Micah, does this need the Kong Enterprise version? as I see here this OIDC plugin is different than the one which is being maintained by Kong which and it is not included in Kong community edition. Is that right?

Micah

It should not require the enterprise version. This post is from a few years back, so things might have changed. At the time, I had to make a minor change to the default plugin. I suspect an updated version of the official plugin would work fine, but I haven’t specifically tested it.

مازیار

Thanks Micah, I will give it a try with all the latest version.