We’ll go through the authorization code flow applied to user authentication processes in our second Kong and Okta tutorial. This series will show you how to implement service authentication and authorization for Kong Konnect and Okta using the OpenID Connect (OIDC) plugin. Parts 1, 3, and 4 cover:
- Implement Client Credentials with Kong Konnect and Okta
- Implement Introspection Flow With Kong Konnect and Okta
- Access control based on Okta’s groups and planes
Table of Contents
- Kong Konnect and Okta Integration Topology
- Add Your Services and Routes to Konnect
- Set Up the Okta Application
- Consume the Route Without a Policy
- Apply the OpenID Connect Plugin
- Test the OpenID Connect Plugin
- Protect Your Applications with Kong Konnect and Okta
You can also watch this tutorial as a screencast.
Kong Konnect and Okta Integration Topology
The Konnect control plane creates new APIs and policies and publishes them to the data plane running as a Docker container in an AWS EC2 instance.
Authorization Code Flow
The authorization code flow goes through the following steps:
- First, a user tries to consume the API.
- If the user doesn’t have a token injected, Kong redirects the user to Okta, the identity provider.
- The user authenticates on Okta and is sent back to Kong with an authorization code token.
- Kong validates the parameters and exchanges the authorization code token by calling Okta’s token endpoint.
Add Your Services and Routes to Konnect
In Konnect’s ServiceHub, I have a service created already. Follow along in our Getting Started with Konnect tutorial to learn how to create a service and routes.
My service has two routes defined already. I used the first service in the previous Kong and Okta tutorial to show the client credentials flow. In this tutorial, I’ll use the second service to apply the OIDC plugin utilizing the authorization code flow.
Set Up the Okta Application
In Okta, I prepared an application to implement the authorization flow already. In the Kong authorization code application, we’re going to use the configured OIDC plugin in addition to the client ID and client secret.
The app has the authorization code option turned on and the signing redirect URI set with the route available in my data plane. That means the authorization code is accepted for this URI only.
Consume the Route Without a Policy
Any user is free to consume the route right now since there’s no policy to control it.
Apply the OpenID Connect Plugin
Just like we did for the client credentials flow tutorial, let’s go back to the Konnect control plane to apply the OIDC plugin and then implement the authorization code flow.
Set the Config.Client ID.
Enter the Config.Client Secret.
Add Okta’s Config.Issuer endpoint.
Click Create to enable the OIDC plugin to the route.
Test the OpenID Connect Plugin
If we try to consume the route again, Kong redirects us to Okta’s user interface to present our credentials.
Once we have presented our correct credentials, Okta authenticates and redirects us back to the API gateway. At this time, we’ll consume the API because we got the identity token injected inside our request.
Then we go to jwt.io to check the token.
Protect Your Applications with Kong Konnect and Okta
Once you’ve set up Konnect and Okta authorization code flow for user authentication, you may find these other tutorials helpful:
- 3 Ways Kong Helps With API Gateway Governance
- Getting Started with Kong Mesh and Open Policy Agent
- Protect Your APIs With Kong Konnect and Fastly (Signal Sciences)
- Use Kong Gateway to Centralize Authentication
If you have any questions about this post, please leave a comment below. To be notified when the OktaDev team posts new content, please follow @oktadev on Twitter, like them on LinkedIn, or subscribe to their YouTube channel.