Kong API Gateway

With Kong and Auth0 you can implement OIDC based authentication processes to protect your APIs.

API gateway authentication is an important way to control the data that is allowed to be transmitted using your APIs. Basically, it checks that a particular consumer has permission to access the API, using a predefined set of credentials.

Kong Gateway has a library of plugins that provide simple ways to implement the best known and most widely used methods of API gateway authentication. Here are some of the commonly used ones:

• Basic Authentication
• Key Authentication
• OAuth 2.0 Authentication
• LDAP Authentication Advanced
• OpenID Connect

Please, refer to the following link to read more about API Gateway authentication

Auth0 is one of the main IdPs in the marketplace today. Kong, on the other hand, is the world’s most popular API gateway, built for hybrid and multi-cloud and optimized for microservices and distributed architectures. The Auth0 and Kong integration provides a powerful and flexible solution for secure API Management infrastructures.

For Enterprise Class Applications, OpenID Connect (OIDC) is the preferred mechanisms for advanced requirements. In fact, when applying OIDC to secure the APIs, we're delegating the Authentication process to an external entity, called Identity Provider.

OIDC is a standard built on top of OAuth and JWT (JSON Web Token). Please, refer to the following link to learn more about OAuth/OIDC and its Flows:

• Authorization Code
• Implicit
• Resource Owner Password
• Client Credentials

Kong Konnect and Auth0 Reference Architecture

The following diagram shows a Reference Architecture including Kong Konnect and Auth0

Prerequisites

1. An Auth0 account and tenant. Sign up for free here.
2. Subscribe to Kong Konnect Plus to get a 30-day trial with all Kong Gateway Enterprise capabilities enabled including IdP integrations with OpenID Connect

For the Client Credentials Flow, the Kong OpenID Connect plugin forwards the credentials passed by the client to the Auth0’s token endpoint. The Client Credentials grant is visualized below:

1. Consumer sends a request with a credential to Kong Gateway.
2. Kong Gateway forwards the credential to Auth0 which returns tokens to the Gateway.
3. Kong Gateway routes the requests with Access Token injected.

The Data Plane

The Kong+Auth0 Environment comprehends a Kong Data Plane, responsible for handling the requests coming from the Consumer and protect the Upstream Services and Application sitting behind it. The Data Plane can be deployment in any available platform including Linux-based Operation Systems, Container, Kubernetes, etc. For the purpose of this guide we assume the Kong Data Plane is running in a Kubernetes cluster.

Kong Certificates and Key

Login to Kong Konnect and go to "Runtimes" -> "Configure Runtime" -> "Kubernetes".

Click on "Generate Certificate" and copy them.

• Save the "Cluster Certificate" as tls.crt
• Save the "Certificate Key" as tls.key
• Save the "Root CA Certificate" as ca.crt

Injecting Key and DCs

Create a namespace and secrets for the Digital Certificates and Key

kubectl create namespace kong-dp
kubectl create secret tls kong-cluster-cert --cert=./tls.crt --key=./tls.key -n kong-dp
kubectl create secret generic kong-cluster-ca --from-file=ca.crt=./ca.crt -n kong-dp

Deploying the Data Plane

Use the following Helm Chart command to deploy the Data Plane. Replace the Control Plane and Telemetry endpoints with the ones provided by Konnect Control Plane.

helm install kong-dp kong/kong -n kong-dp \
--set ingressController.enabled=false \
--set image.repository=kong/kong-gateway \
--set image.tag=2.8.0.0-alpine \
--set admin.enabled=false \
--set env.role=data_plane \
--set env.database=off \
--set env.anonymous_reports=off \
--set env.vitals_ttl_days=732 \
--set env.cluster_mtls=pki \
--set env.cluster_control_plane=<b>your-control-plane-endpoint</b>:443 \
--set env.cluster_server_name=<b>your-control-plane-endpoint</b> \
--set env.cluster_telemetry_endpoint=<b>your-control-plane-telemetry-endpoint</b>:443 \
--set env.cluster_telemetry_server_name=<b>your-control-plane-telemetry-endpoint</b> \
--set env.cluster_ca_cert=/etc/secrets/kong-cluster-ca/ca.crt \
--set env.cluster_cert=/etc/secrets/kong-cluster-cert/tls.crt \
--set env.cluster_cert_key=/etc/secrets/kong-cluster-cert/tls.key \
--set env.lua_ssl_trusted_certificate=/etc/secrets/kong-cluster-cert/tls.crt \
--set proxy.enabled=true \
--set proxy.type=LoadBalancer \
--set enterprise.enabled=true \
--set enterprise.portal.enabled=false \
--set enterprise.rbac.enabled=false \
--set enterprise.smtp.enabled=false \
--set manager.enabled=false \
--set portal.enabled=false \
--set portalapi.enabled=false \
--set env.status_listen=0.0.0.0:8100 \
--set secretVolumes[0]=kong-cluster-cert \
--set secretVolumes[1]=kong-cluster-ca \
--set env.log_level=debug

Create the Kong Service Package

• Login to Konnect and click on Add New Service
• Create a new httpbinservice Service with v1 version
• Click on Create

Create the Service's Implementation

• Click on version v1
• Click on New Implementation
• Type http://httpbin.org for URL and click on Next
• Type httpbinroute for Name. Click on + Add Path and type /httpbin. Click on Create.

Consume the Kong Route

Use the External IP Address provided by your Kubernetes cluster. For example, the following command shows the AWS EKS services:

$ kubectl get service --all-namespaces

NAMESPACE     NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)                      AGE
default       kubernetes           ClusterIP      10.100.0.1       <none>                                                                   443/TCP                      63m
kong-dp       kong-dp-kong-proxy   LoadBalancer   10.100.201.216   a3337b1604fb9419190b54634515fcb3-183430464.eu-west-3.elb.amazonaws.com   80:32015/TCP,443:32038/TCP   108s
kube-system   kube-dns             ClusterIP      10.100.0.10      <none>                                                                   53/UDP,53/TCP                63m

$ http a3337b1604fb9419190b54634515fcb3-183430464.eu-west-3.elb.amazonaws.com/httpbin/get
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 550
Content-Type: application/json
Date: Tue, 15 Feb 2022 18:49:03 GMT
Server: gunicorn/19.9.0
Via: kong/2.7.1.1-enterprise-edition
X-Kong-Proxy-Latency: 13
X-Kong-Upstream-Latency: 165

{
    "args": {},
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip, deflate",
        "Host": "httpbin.org",
        "User-Agent": "HTTPie/3.0.2",
        "X-Amzn-Trace-Id": "Root=1-620bf59f-725aac5a4390f9cc708a05e7",
        "X-Forwarded-Host": "a3337b1604fb9419190b54634515fcb3-183430464.eu-west-3.elb.amazonaws.com",
        "X-Forwarded-Path": "/httpbin/get",
        "X-Forwarded-Prefix": "/httpbin"
    },
    "origin": "192.168.37.246, 35.180.228.21",
    "url": "http://a3337b1604fb9419190b54634515fcb3-183430464.eu-west-3.elb.amazonaws.com/get"
}

Kong + Auth0 - OIDC Client Credentials Grant

The Client Credentials Flow is defined by OAuth to address scenarios like Application Authentication, Machine-to-Machine, Microservices Accounts, etc. Please refer to this link to learn more about Client Credentials.

Auth0 API Creation

Let's create our first Auth0 API:

• Login to Auth0 console using your endpoint like this: https://auth0.com
• Click on Applications -> APIs -> + Create API. Create a new API named KongClientCredentials with https://clientcredentials.com as its Identifier.
• Click on Create
• Click on the Machine to Machine Applications tab. As you can see Auth0 automatically created a Test Application for us. The Application is also already authorized to use the API.
• Click on the KongClientCredentials (Test Application) Application link. Click on the "eye" button to see the client secret. Save Domain, Client ID and Client secret. They'll be used to configure the Kong OIDC plugin and consume the API. In our case:
  • Domain: dev-xxxxxx.us.auth0.com
  • Client ID: some_client_id
  • Client Secret: some_client_secret

Enable the OIDC plugin to the Route

Let's apply the OIDC plugin to the Route with the specific Auth0 settings:

• Issuer Endpoint
• Scope

Check the OIDC Plugin page for more information about the plugin.

Go back to Kong Konnect Control Plane and click on httpbinroute again. Click on Add Plugin. Choose OpenID Connect plugin

Fill in the form with the following configuration:

• Config.Issuer: use the Auth0 Domain we saved previously https://dev-xxxxxx.us.auth0.com/.well-known/openid-configuration
• Config.Scopes: delete the openid scope set by default
• Config.Token Post Args Names: it should be set with audience
• Config.Token Post Args Values: it should be set with the API Identifier we used to create the Auth0 API: https://clientcredentials.com

Click on Create.

Consume the Route with Client Id and Client Secret. We should be able to consume the Kong Route with our Client Id and Client Secret:

$ http a131cf848dbd44e45af06511412201fe-1032110377.eu-west-3.elb.amazonaws.com/httpbin/get -a some_client_id:some_client_secret
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 1316
Content-Type: application/json
Date: Wed, 16 Feb 2022 11:15:10 GMT
RateLimit-Limit: 5
RateLimit-Remaining: 4
RateLimit-Reset: 50
Server: gunicorn/19.9.0
Set-Cookie: session=Zhu08guEpxppKI_E8vTRXg|1645013709|rIDhFNGnbGlOsNM0sIyeqMkBg3tN; Path=/; SameSite=Lax; HttpOnly
Via: kong/2.7.1.1-enterprise-edition
X-Cache-Key: 299e9cfd9462b37fc817946be53b791e
X-Cache-Status: Miss
X-Kong-Proxy-Latency: 1074
X-Kong-Upstream-Latency: 169
X-RateLimit-Limit-Minute: 5
X-RateLimit-Remaining-Minute: 4

{
    "args": {},
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip, deflate",
        "Authorization": "Bearer some_bearer_token",
        "Host": "httpbin.org",
        "User-Agent": "HTTPie/3.0.2",
        "X-Amzn-Trace-Id": "Root=1-620cdcbe-3e2ecc8c33302c050a43de4b",
        "X-Forwarded-Host": "a131cf848dbd44e45af06511412201fe-1032110377.eu-west-3.elb.amazonaws.com",
        "X-Forwarded-Path": "/httpbin/get",
        "X-Forwarded-Prefix": "/httpbin"
    },
    "origin": "192.168.37.246, 35.180.228.21",
    "url": "http://a131cf848dbd44e45af06511412201fe-1032110377.eu-west-3.elb.amazonaws.com/get"
}

The -a option is a shortcut for --auth

If you try to consumer the Route with invalid ClientId/ClientSecret pair you get a 401 error code:

$ http a131cf848dbd44e45af06511412201fe-1032110377.eu-west-3.elb.amazonaws.com/httpbin/get -a some_client_id:6F3nCynbE6Hgs9cUSWfMYvE2_
HTTP/1.1 401 Unauthorized
Connection: keep-alive
Content-Length: 26
Content-Type: application/json; charset=utf-8
Date: Wed, 16 Feb 2022 11:17:10 GMT
Server: kong/2.7.1.1-enterprise-edition
WWW-Authenticate: Bearer realm="dev-xxxxxx.us.auth0.com"
X-Kong-Response-Latency: 642

{
    "message": "Unauthorized"
}

Please refer to the OIDC plugin documentation page to learn how to configure all OIDC Grants specifically with Auth0