You can use Kong consumers for authorization and dynamically map
claim values to Kong consumers. This means that we restrict the access to
only those that do have a matching Kong consumer. Kong consumers can have ACL
groups attached to them and be further authorized with the
Kong ACL plugin.
In most cases, the OpenID Connect plugin relies on a third party identity provider (IdP).
The examples in this guide use Keycloak as a sample IdP.
Expand the following sections to configure Keycloak and Kong Gateway.
All the *.test domains in the following examples point to the localhost (127.0.0.1 and/or ::1).
We use Keycloak as the identity provider in the following examples,
but the steps will be similar in other standard identity providers. If you encounter
difficulties during this phase, refer to the Keycloak documentation.
Create a confidential client kong with private_key_jwt authentication and configure
Keycloak to download the public keys from [the OpenID Connect Plugin JWKS endpoint][json-web-key-set]:
Create another confidential client service with client_secret_basic authentication.
For this client, Keycloak will auto-generate a secret similar to the following: cf4c655a-0622-4ce6-a0de-d3353ef0b714.
Enable the client credentials grant for the client:
(Optional) Create another confidential client cert-bound with settings similar to the service client created previously.
From the Advanced tab, enable the OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled toggle.
(Optional, to test mTLS Client Authentication) Create another confidential client client-tls-auth with settings similar to the service client created above.
From the Credentials tab, select the X509 Certificate Client Authenticator and fill the Subject DN field so that it matches the Kong client certificate’s, e.g.: CN=JohnDoe, OU=IT.
Create a verified user with the name: john and the non-temporary password: doe that can be used with the password grant:
The Keycloak default https port conflicts with the default Kong TLS proxy port,
and that can be a problem if both are started on the same host.
Note: The mTLS Client Authentication, along with the proof of possession feature that validates OAuth 2.0 Mutual TLS Certificate Bound Access Tokens, both require configuring Keycloak to validate client certificates with mTLS using the --https-client-auth=request option, and to configure TLS appropriately, including adding the trusted client certificates to the truststore. For more information, refer to the Keycloak documentation.
Configure Kong Gateway
Create a service:
http -f put :8001/services/openid-connect url=http://httpbin.org/anything
Check the discovery cache: http :8001/openid-connect/issuers.
It should contain Keycloak OpenID Connect discovery document and the keys.
At this point you have created a service, routed traffic to the service, and
enabled OpenID Connect plugin on the service.
The following examples are built with simplicity in mind, and
are not meant for a production environment.
Because httpbin.org is the upstream service in these examples, we highly
recommended that you do not run these examples with a production identity
provider as there is a high chance of leaking information.
The examples also use the plain HTTP protocol, which you should
never use in production.