In our last Kong and Okta tutorial, we will implement a basic access control policy based on Okta’s groups and planes. This series will show you how to implement service authentication and authorization for [Kong Konnect](https://konghq.com/kong-konnect)Kong Konnect and [Okta](https://www.okta.com)Okta using the [OpenID Connect](https://konghq.com/blog/openid-connect-api-gateway)OpenID Connect ([OIDC](https://docs.konghq.com/hub/kong-inc/openid-connect)OIDC) plugin. Parts 1, 2 and 3 covered:
**OIDC claims** are a piece of information inserted about an entity. Name and picture are claim examples for users.
**OIDC scopes** are a group of claims.
In this tutorial, we'll define a new claim based on an Okta group. The claim will be included in all scopes defined. The OIDC plugin must check if the coming tokens have this specific claim to allow the Kong route consumption. Only users who are part of the Okta group will have the claim included in the token and will be able to consume the route.
In my example, I already created two users and a group. The group has only one member.
The new claim will be based on this group, so only its members will have permission to go through the Kong route.
The new Kong claim definition is based on the Kong group. It'll be included in any scope for each access token issued.
Let’s run a token preview to check the tokens and claim out. For the first request, we can try the user who’s not a Kong group member. As expected, the access token does not have a Kong claim inside of it.
If we try the other user that belongs to the Kong group, the access token will be different. Here’s the Kong claim inside our token.
Let’s check our Kong route with the OIDC plugin enabled. According to the parameters in the screenshot below, the plugin should check if the token has the Kong claim defined by Okta. So in this sense, the route should be consumed only by users who are members of the Kong group.
The new settings should be:
Let's have both users consume the route. The process will be similar to what we already did in Okta’s token preview process. For the first request, let's try the user who isn't in the Kong group. As expected, we shouldn’t be able to consume the route.
We are trying to consume the route, but since we don’t have any token injected inside our request, the API gateway redirects us to Okta to present our credentials.
And after getting authenticated, Okta is redirecting us back to the API gateway. However, since the token doesn’t have the claim inside it, the gateway says "forbidden" and won’t allow us to consume the route.
Let’s try the other user who is a member of the Kong group. Again, we try to consume the route, getting redirected to Okta, but we’re going to use the second user this time.
After getting authenticated, Okta redirects us back to the API gateway. This time, our token has the Kong claim we defined in Okta previously.
If we go to [jwt.io](http://jwt.io)jwt.io, we will decode the JWT token and check the token and the claim inside it.
[Start a free trial](https://konghq.com/kong-konnect)Start a free trial, or [contact us](https://support.konghq.com/support/s)contact us if you have any questions as you're getting set up.
Once you've set up Konnect and Okta access control policies, you may find these other tutorials helpful:
Ensuring secure access to applications and APIs is critical. As organizations increasingly adopt microservices architectures and cloud native solutions, the need for robust, fine-grained access control mechanisms becomes paramount. This is where the
[](https://konghq.com/blog/engineering/secure-access-control-with-opa-and-kong)
In the modern IT stack, API gateways act as the first line of defense against attacks on backend services by enforcing authentication/authorization policies and validating and transforming requests. When backend services are protected with a token-b
[](https://konghq.com/blog/engineering/zero-trust-oauth-2-0-mtls-client-authentication)
With digital transformation shifting networks into the cloud — from remote workforces to online banking — cyberattacks are growing more prevalent and sophisticated. Legacy security models like VPNs and perimeter-based firewalls are proving inadequat
[](https://konghq.com/blog/engineering/microsegmentation-and-zero-trust-security)
With its flexible querying capabilities, GraphQL makes it easy to combine data from multiple sources into a single endpoint. GraphQL and API management go hand in hand to build next-generation API platforms. However, GraphQL's features can als
[](https://konghq.com/blog/engineering/graphql-security-vulnerabilities)
As APIs and microservices evolve, the architecture used to secure these resources must also mature. Utilizing a token-based architecture to protect APIs is a robust, secure and scalable approach, and it is also much safer than API keys or basic au
[](https://konghq.com/blog/engineering/token-based-access-control)
As more and more companies move to a multi-cloud strategy and increase usage of a cloud native infrastructure , API providers are under a lot of pressure to deliver APIs at scale in multi-cloud environments. At the same time, APIs should follow eac
[](https://konghq.com/blog/engineering/api-authorization)
This tutorial will walk through a common use case for the Kong Gateway Key Authentication plugin : using API key authentication to protect a route to an API server endpoint. It’s a simple use case, but it will give you the foundation to deploy and
[](https://konghq.com/blog/engineering/kong-gateway-key-authentication)