THE CLOUD

CONNECTIVITY COMPANY

Kong Gateway Operations

OIDC Plugin

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 1
 Course Agenda
1. Kong Gateway Installation 6. Advanced Plugins Review
2. Upgrading Kong Gateway 7. Troubleshooting
3. Securing Kong 8. Monitoring / Observability
4. Securing Services on Kong 9. Administering Kong Gateway
using Deck
5. OIDC Plugin

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 2
Learning Objectives
1. Understand and explain how to integrate the OIDC plugin
2. Be able to administer OIDC plugin
3. Understand some basic OIDC workflows

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 3
 Lab: OIDC Plugin in Kong

To set up your lab environment for this lesson, run the 'setup' command, then select option '5'

$ setup
1) Kong Gateway Installation
2) Upgrading Kong Gateway
3) Securing Kong Gateway
4) Securing Services on Kong
5) OIDC Plugin
6) Kong Vitals
7) Advanced Plugins Review
8) Troubleshooting
9) Reset Virtual Machine
10) Quit
Please select the lesson you wish to set up: 5

Setting up for lesson '5 OIDC Plugin'

...
THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 4
 What is OIDC?

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 5
 What is OIDC?

OpenID Connect/OAuth 2.0 authentication framework provides multiple ways to secure services for
different scenarios, including User to Service and Service to Service scenarios.

A detailed description of OIDC is beyond the scope of this course

Kong supports many authentication frameworks and standards to properly govern and secure Services.
For the OIDC authentication framework, Kong supports a variety of 3rd party providers such as Auth0,
Okta, MS Azure ID, Google, Amazon AWS Cognito, etc. As long as a provider supports OpenID Connect
standards, Kong should be able to work with it.

An identity provider (IdP) is a system entity that creates, maintains, and manages identity information for
principals and also provides authentication services to relying applications within a federation or
distributed network.

For this workshop, we will be using a 3rd party Identity Provider (IdP), Keycloak.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 6
 OIDC Sample Workflow (very simplified)
Kong (Client) 3 Authorization server (IDP)
2
Go to authorization server
Myshop.com/oidc keycloak.com
(frontend)
1 Redirect URI: myshop.com/callback
Email
Response type: code
Log in with Keycloak Scope: openid profile Password

Resource owner keycloak.com

for
/userinfo n c ode
tio 4
7 o riza n
e au t h
I D toke Request consent
g and
Get user info with han
access token Exc s token from resource owner
es 6
Acc

myshop.com/callback keycloak.com
(backend) Back to redirect URI Allow Myshop to access
With authorization code your profile
Hello Joe!
5 Yes No

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 7
Kong Platform Security - Securing the API - Authentication
● OpenID Connect (OIDC) ENTERPRISE

○ Integrate with third party IdP

○ Kong as OAuth2 Resource Server or OIDC Relying Party
○ Same functionality as OAuth2 Introspection, and more
○ Supported OIDC providers
■ Okta
■ Azure AD
■ Google
■ Auth0
■ AWS Cognito
■ KeyCloak
■ OpenAM
■ etc.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 8
 The Kong OIDC Plugin
The OpenID Connect plugin standardizes the integration with 3rd party identity providers. The plugin
can be used to implement Kong as a (proxying) OAuth 2.0 Resource Server (RS) and/or as an
OpenID Connect Relying Party (RP) between the client and the upstream service.

Kong’s OIDC plugin is quite versatile, with around 200 parameter settings. It would be useful to know what
combination of configurations are best fitted for your use-case. It supports a number of credential and
grant types:

● Signed JWT access tokens (JWS) ● Username and password

● Opaque access tokens ● Client credentials

● Refresh tokens ● Session cookies

● Authorization code

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 9
 Deploy an Identity Provider (IdP)

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 10
 Task: Deploy Keycloak
Deploying and configuring an IDP is beyond the scope of this course, so we have deployed
Keycloak by way of a container. To review the configuration for the container look at the
keycloak section of the docker-compose.yaml file used in this course.
$ cd ~/KGIL-201
$ yq '.services.keycloak' docker-compose.yaml

Before we continue, it is worth noting that during the startup of keycloak, a number of settings
were provisioned via the configuration file /data/kong_realm_template.json. You can,
for example, list the users:
$ jq -r '.users[].username' misc/kong_realm_template.json

admin
employee
partner
service-account-kong

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 11
 Deploying the OIDC Plugin

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 12
 Task: Add a Service to use with OIDC
Create a service named my-oidc-service to proxy requests to URL mockbin/request
$ http POST localhost:8001/services \
name=my-oidc-service \
url=http://mockbin:8080/request

HTTP/1.1 200 OK
...
The /request endpoint simply returns anything passed in request data.

Now create a route for service my-oidc-service with path /oidc.

$ http -f POST localhost:8001/services/my-oidc-service/routes \
name=my-oidc-route \
paths=/oidc

HTTP/1.1 201 Created

...
THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 13
 Task: Confirm Service Functionality
Now, let's see what happens when you make the call to the API where Kong proxies mockbin

$ http GET localhost:8000/oidc

HTTP/1.1 200 OK
...

The response should be an HTTP 200 OK.

You have not configured authentication yet, so Kong is proxying your API request as expected

In the next section we will configure Kong to send your client to the Keycloak IDP to be authenticated
before it proxies the request.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 14
 Task: Set Keycloak settings
When configuring the OpenID connect we need to specify a number of Keycloak settings, namely

● client_secret
● issuer
● client_id

The Client Secret is specified in the Keycloak configuration file kong_realm_template.json so we'll
us jq to extract it into an environment variable - the other two will be hard-coded

$ CLIENT_SECRET="$(jq '.clients[] | select(.clientId == "kong")'

~/KGIL-201/misc/kong_realm_template.json | jq .secret | xargs)"

$ export
KEYCLOAK_CONFIG_ISSUER="http://keycloak:8080/auth/realms/kong/.well-known/openid-configuration"

$ export KEYCLOAK_REDIRECT_URI/oidc="http://localhost:8000/oidc"

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 15
 Task: Add OpenID Connect Plugin
The OIDC plugin allows Kong to protect your Services with a 3rd party Identity Provider using the OpenID Connect,
OAuth 2.0 and JWT standards. Let's add the OpenID Connect plugin to the oidc-route

$ http -f POST localhost:8001/routes/my-oidc-route/plugins \

name=openid-connect \
config.issuer=$KEYCLOAK_CONFIG_ISSUER \
config.client_id=kong \
config.client_secret=$CLIENT_SECRET \
config.redirect_uri=$KEYCLOAK_REDIRECT_URI/oidc \
config.response_mode=form_post \
config.ssl_verify=false \
config.introspection_check_active=false

HTTP/1.1 201 Created

We'll review these parameters next.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 16
 OpenID Connect Plugin Configuration Parameters
We've pre-created variables with the following values the OpenID Connect plugin expects:

● config.issuer - This parameter tells the plugin where to find discovery information

● config.client_id - The client_id of the OpenID Connect client registered in OpenID Connect
Provider

● config.client_secret - The client_secret of the OpenID Connect client registered in OpenID Connect
Provider

● config.redirect.uri - This parameter defines the URL the IDP will redirect the user to after a
successful authentication

● config.response_mode - This parameter specifies the response mode the IDP should respond with

● config.ssl_verify - This parameter is set to false for this environment since the Keycloak uses a
self signed certificate

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 17
 Task: Verify Protected Service
Let's make a call to the API that is now protected with the OpenID Connect plugin

$ http GET localhost:8000/oidc

HTTP/1.1 302 Moved Temporarily

...

The response should be HTTP 302 Moved Temporarily. This is due to all traffic hitting our
route now needing to be properly authenticated. Now try

$ http GET localhost:8000/oidc -a user:password

HTTP/1.1 401 Unauthorized

...

The response should be HTTP 401 Unauthorized as 'user' was not specified in the Keycloak
configuration we loaded.
THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 18
 Task: View Kong Discovery Information from IDP
You can view that Kong has loaded the discovery information from the IDP

$ http GET localhost:8001/openid-connect/issuers

HTTP/1.1 200 OK
...

You can filter the response to get to specific information:

$ http -b GET localhost:8001/openid-connect/issuers | jq -r .data[].issuer

http://keycloak:8080/auth/realms/kong/.well-known/openid-configuration

Opening the URL you got in a browser will show you the current configuration of the plugin.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 19
 OIDC Examples
Now that we have OIDC configured, let's look at a few examples.

There are many different authentication scenarios to choose from, for example.

● password grant
● client credentials
● authorization code
● bearer token

and a number of authorization scenarios relating to for example

● Roles
● Audience Required

In this course, we will cover a selection of authentication and authorization scenarios

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 20
Authentication with Password Grant

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 21
 Password Grant Authorization Flow

In this section, we will use Password Grant. With this grant, Kong will call the token endpoint of the IDP on
behalf of the end user to obtain short-lived tokens.

In Keycloak, a user=employee with credentials=test

has already been created. Let's utilize this user for the
password grant.

Note: The Password Grant flow is used in legacy use cases

because the client application has to collect and send a user's
credentials to the IDP to authenticate the user. The latest
OAuth 2.0 Security Best Current Practice disallows the
password grant entirely.

A more modern, secure, approach is to use the Authorization

Code flow.
THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 22
 Task: Confirm Keycloak is configured for Password Grant
Before getting an access token for user, let’s confirm Keycloak is configured for Password Grant, and that
password can be passed in request body/header/query:
$ OIDC_PLUGIN_ID=$(http GET localhost:8001/routes/my-oidc-route/plugins/ \
| jq -r '.data[] | select(.name == "openid-connect") | .id')

$ http -b GET localhost:8001/plugins/$OIDC_PLUGIN_ID \

| jq .config.auth_methods

"Password", . . .

$ http -b GET localhost:8001/plugins/$OIDC_PLUGIN_ID \

| jq .config.password_param_type

"header",
"query",
"body"

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 23
 Task: Provide credentials to Kong and retrieve Access Token
Use employee/test credentials to get an access token for the user:
$ http GET localhost:8000/oidc -a employee:test

HTTP/1.1 200 OK
Note the bearer token and session cookie in the headers. This is the short-lived token that can be used by
the client application to access protected endpoints. The service we're using simply echoes back what's
been sent.

You can decode this token at https://jwt.io or from CLI to inspect the contents of it.

$ BEARER_TOKEN=$(http localhost:8000/oidc -a employee:test | jq -r

'.headers.authorization' | cut -c 7-)

$ jwt decode $BEARER_TOKEN

As you can see, the main disadvantage of password grant is that user credentials are exposed
to the client application.
THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 24
 Authenticate with Bearer Token
Grant

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 25
 Authenticate with Bearer Token Grant
■ Token Authentication (also called Bearer
authentication) is an HTTP authentication scheme
that involves security tokens called bearer tokens.
■ In this flow, the client or application has a token.
■ Kong can validate the token using signature when it
is JWT, or validate with Introspect endpoint when it
is an opaque token.
■ With the token validated, Kong can leverage claims
in JWT tokens or claims in introspection results to
drive access decisions such as consumer mapping,
group mapping etc.
■ In this section, you will use the bearer token
generated by the authentication server for the
employee user to authenticate to the Service.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 26
 Task: Get a token and authenticate with it
Let's obtain a bearer token for the user from the IDP directly using credentials:

$ BEARER_TOKEN=$(http -f POST localhost:8080/auth/realms/kong/protocol/openid-connect/token \

grant_type=password \
client_id=kong \
client_secret=$CLIENT_SECRET \
username=employee \
password=test | jq -r .access_token | xargs)

You can verify this token

$ echo $BEARER_TOKEN

eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJKen...

Use the bearer token to authenticate to the Service:

$ http -h GET localhost:8000/oidc authorization:"Bearer $BEARER_TOKEN" | head -1

Since the200
HTTP/1.1 bearer
OK token is valid and associated with the employee user, the response is an 200 OK

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 27
 Task: Decoding the Bearer Token
Decode the bearer token using http://jwt.io. Here is an explanation for the displayed fields:

Bearer Token: This the encoded bearer token.

Issuer: This is the config.issuer you specified in during the initial

Keycloak configurations.

Realm Access: This shows the Realm Access and the roles associated
with the user.

Token Information: This shows the scope, email, name, etc. that is
associated with this user. Notice the given name and family name that
you specified in the Keycloak configurations.

As we move into the Authorization section, you will notice how we can
use the claims and scopes in the token to drive authorization decisions.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 28
 Authorization

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 29
 Authorization with OpenID Connect Overview

To this point we have focused on authentication for various application use cases

In this section, we will focus on authorization to control access to Services.

There are a number of popular approaches to authorizing API access with Kong and the OpenID
Connect plugin, including:

● Authorization with Consumer Mapping

● Authorization with Roles

● Authorization with Audience Required

● Authorization with Scopes Required

We will look at authorization with roles as well as Rate Limiting Different Consumers

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 30
 Authorization with Consumer
Mapping

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 31
 Authorization with Consumer Mapping

● One way to authorize access to services with Kong is to require external IDP users to map
to a Kong consumer.
● Kong Consumer objects are not necessarily singular users/consumers but they can also be
constructs of a "Consumer package".
● For example, if you have a Consumer named "gold", this could represent all the consumers
that have a "gold" tier account with your organization.
● Consumer objects let you control who can access your APIs, report on traffic using logging
and allow applying additional restrictions like rate limits..
● In this section, you’ll authorize access to the employee user via consumer mapping.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 32
 Authorization with Consumer Mapping

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 33
 Task: Configure a consumer & modify OIDC plugin to require preferred_username
Configure a consumer with username=employee in Kong using the CLI.
$ http PUT localhost:8001/consumers/employee

Now patch OIDC plugin to require a consumer with the preferred_username claim
$ OIDC_PLUGIN_ID=$(http GET localhost:8001/routes/my-oidc-route/plugins/ \
| jq -r '.data[] | select(.name == "openid-connect") | .id')

$ http -f PATCH localhost:8001/plugins/$OIDC_PLUGIN_ID \

config.consumer_claim=preferred_username

You response should see quite a bit of output

HTTP/1.1 200 OK
{
"config": {
"anonymous": null,
"audience": null,
...

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 34
 Task: Verify authorization works for a user mapped to a Kong consumer
Let's verify a user whose name matches a Kong consumer can successfully authenticate and is
authorized. Use the employee consumer to verify.

$ http -h GET localhost:8000/oidc -a employee:test

The employee user can still proxy but now the headers x-consumer-ID and x-consumer-username are
added

Also, if you inspect the Bearer token and paste it in the https://jwt.io/ website, you will see that the claim
preferred_username=employee.

HTTP/1.1 200 OK
...
"X-Consumer-Id": "41d7c210-5f8e-4eca-9285-20133ef36ea3",
"X-Consumer-Username": "employee",
...

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 35
 Task: Verify authorization is forbidden for a user not mapped to a consumer
Let's verify a user whose name does not match a Kong consumer is denied access. Use the partner
consumer to verify.

$ http GET localhost:8000/oidc -a partner:test

This user is forbidden because the partner user is not mapped to the consumers in Kong.

HTTP/1.1 403 Forbidden

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 36
 Task: Add & Verify Rate Limiting
Now that a Kong Consumer for the user employee exists, apply a Rate Limiting policy to the Consumer

$ http -f POST localhost:8001/consumers/employee/plugins \

name=rate-limiting \
config.minute=3 \
config.policy=local

Execute the same request 5 times in less than a minute to see rate limiting plugin in action:

$ for ((i=1;i<=5;i++)); do http GET localhost:8000/oidc -a employee:test; done

HTTP/1.1 429 Too Many Requests

...
X-RateLimit-Limit-Minute: 3
X-RateLimit-Remaining-Minute: 0
...

The last 2 requests trigger the rate limit as seen above.

THE CLOUD CONNECTIVITY COMPANY
Kong Confidential 37
 Task: Cleanup
Disable this consumer mapping by leaving the consumer_claim blank. We also remove the rate limiting.
This is important to progress with the next section.

$ http -f PATCH localhost:8001/plugins/$OIDC_PLUGIN_ID \

config.consumer_claim= \
| jq . | grep consumer_claim

"consumer_claim": null

$ RATE_PLUGIN_ID=$(http GET localhost:8001/consumers/employee/plugins/ \

| jq -r '.data[] | select(.name == "rate-limiting") | .id')

$ http DELETE localhost:8001/plugins/$RATE_PLUGIN_ID

HTTP/1.1 204 No Content

...

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 38
 Authorization with Roles

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 39
 Authorization with Roles

■ In this section we cover how to drive access to services via Roles from the IDP using the
ACL plugin in conjunction with the OpenID Connect plugin.
■ This scenario is useful to drive user access based on user roles managed in the IDP with
no need to define or manage identities in Kong.
■ Another scenario this is useful for is when different types of users authenticate differently,
for example external users authenticate via Key-Auth while internal users authenticate via
LDAP.
■ To accomplish this, we will setup the OpenID Connect plugin to read the user's roles as
defined in the IDP, then configure the ACL plug-in to require users to have specific roles
before they can access the services.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 40
 Task: Modify the OIDC plugin to search for user roles in a claim

Shown is a snippet of the JWT token

We will patch the OpenID Connect plugin

to search the array
realm_access→roles for user roles.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 41
 Task: Modify the OIDC plugin to search for user roles in a claim
Run the following commands to patch the OpenID Connect plugin

$ OIDC_PLUGIN_ID=$(http GET localhost:8001/routes/my-oidc-route/plugins/ \

| jq -r '.data[] | select(.name == "openid-connect") | .id')

$ http -f PATCH localhost:8001/plugins/$OIDC_PLUGIN_ID \

config.consumer_claim= \
config.authenticated_groups_claim=realm_access \
config.authenticated_groups_claim=roles \
| jq -r '.config.authenticated_groups_claim'

[
"realm_access",
"roles"
]

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 42
 Task: Configure the ACL plugin and allow access to users with the admins role

$ http -f POST localhost:8001/routes/my-oidc-route/plugins \

name=acl \
config.allow=admins

The ACL plug-in is now applied and requires users to be a member of the internal role to access the
service.

$ http GET localhost:8000/oidc -a employee:test

HTTP/1.1 403 Forbidden

This user is forbidden because the user is not a member of the internal role.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 43
 Task: Modify the ACL plugin to require users being members of the role
demo-service to access the service
$ ACL_PLUGIN_ID=$(http GET localhost:8001/routes/my-oidc-route/plugins \
| jq -r '.data[] | select(.name == "acl") | .id')
$ http -f PATCH localhost:8001/routes/my-oidc-route/plugins/$ACL_PLUGIN_ID \
config.allow=demo-service

Access the route with user employee

$ http GET localhost:8000/oidc -a employee:test

HTTP/1.1 200 OK

Notice the user is now able to access the service. This method allows the identity management process
to drive which services secured by Kong the user has access to.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 44
 Task: Cleanup
We need to clean up this set of plugins. This is important to progress with the next section.

$ http DELETE localhost:8001/routes/my-oidc-route/plugins/$ACL_PLUGIN_ID

This results as below

HTTP/1.1 204 No Content

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 45
 Authorization and Rate Limiting
Different Consumers

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 46
 Authorization and Rate Limiting Different Consumers
■ In a previous section, we covered how Consumers can be authorized and rate limited.
■ In this section, we will expand on that example further to implement a scenario where internal
users, say employees, are rate limited at 5 requests per minute but external users, say
partners, are rate limited at 1000 requests per minute.
■ This scenario is useful when you have a service accessible by both free and paid users.
■ Both user types are accessing the same service but we want to provide our paid subscribers
preferential rate limits.
■ Another use-case scenario is when multiple subscriptions levels exist for a service, say Silver,
Gold and Platinum.
■ We can enforce different rate limits for different subscription levels, for example, providing
better rate limits to our higher paying consumers.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 47
 Task: Modify & verify the plugin to require a scope of admins
To enable this scenario we will configure the OpenID Connect plugin to map the preferred_username
claim to a Kong Consumer but optionally require the Kong Consumer to exist.

Essentially, this is saying, if a Kong Consumer doesn't exist, allow the user to access but allow Kong to
track who the user is.
$ OIDC_PLUGIN_ID=$(http GET localhost:8001/routes/my-oidc-route/plugins/ \
| jq -r '.data[] | select(.name == "openid-connect") | .id')
$ http -f PATCH localhost:8001/plugins/$OIDC_PLUGIN_ID \
config.consumer_claim=preferred_username \
config.consumer_optional=true

The result shows the updated config:

"consumer_claim": [
"preferred_username"
],
"consumer_optional": true,
"credential_claim": [
"sub"

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 48
 Task: Configure Rate Limiting Plugins
To implement our desired scenario, we're going to apply a rate limit to our route of 5 requests per
minute and apply a rate limit of 1000 requests per minute to our consumer. Another way to look at
it is, any user without a Kong Consumer who is rate limited differently, will be rate limited at 5
requests per minute.

$ http -f POST localhost:8001/routes/my-oidc-route/plugins \

name=rate-limiting \
config.minute=5 \
config.policy=local

$ http -f POST localhost:8001/consumers/employee/plugins \

name=rate-limiting \
config.minute=1000 \
config.policy=local

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 49
 Task: Verify Rate Limits
Verify the rate limit of the partner. The partner user is allowed to access the Service but is rate limited at 5
requests per minute.

$ for ((i=1;i<=6;i++)); do http -h GET localhost:8000/oidc -a partner:test; done

HTTP/1.1 200 OK
...
X-Kong-Upstream-Latency: 2
X-RateLimit-Limit-minute: 5
X-RateLimit-Remaining-minute: 4

$ for ((i=1;i<=12;i++)); do http GET localhost:8000/oidc -a employee:test; done

HTTP/1.1 200 OK
...
X-Kong-Upstream-Latency: 21
X-RateLimit-Limit-Minute: 1000
X-RateLimit-Remaining-Minute: 988

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 50
 Summary
In this lesson we've looked at
● What is OIDC?

● Deploying Keycloak as OIDC provider

● Deploying the OIDC Plugin

● Authenticate with Password Grant

● Authenticate with Bearer Token Grant

● Authorization with Consumer Mapping

● Authorization with Roles

● Authorization and Rate Limiting Different Consumers

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 51
 Questions?

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 52
 What's next?

In the next lesson we will look at Kong Gateway Advanced Plugins.

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 53
Thank You

THE CLOUD CONNECTIVITY COMPANY

Kong Confidential 54