You are browsing documentation for an outdated plugin version.
Session auth workflow
The OpenID Connect plugin can issue a session cookie that can be used for further session authentication. To make OpenID Connect issue a session cookie, you need to first authenticate with one of the other grants or flows that this plugin supports. For example, the authorization code flow demonstrates session authentication when it uses the redirect login action.
The session authentication portion of the flow works like this:
sequenceDiagram autonumber participant client as Client
(e.g. mobile app) participant kong as API Gateway
(Kong) participant httpbin as Upstream
(backend service,
e.g. httpbin) activate client activate kong client->>kong: service with
session cookie deactivate client kong->>kong: load session cookie kong->>kong: verify session activate httpbin kong->>httpbin: request with
access token httpbin->>kong: response deactivate httpbin activate client kong->>client: response deactivate kong deactivate client
Prerequisites
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.
Configure Keycloak
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
withprivate_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
withclient_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 theservice
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 theservice
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
. -
(Optional, to test Demonstrating Proof-of-Possession Client Authentication) Create another confidential client
client-dpop-auth
with settings similar to theservice
client created above. From the Advanced tab, enable theOAuth 2.0 DPoP Bound Access Tokens Enabled toggle. - Create a verified user with the name:
john
and the non-temporary password:doe
that can be used with the password grant:
Alternatively you can download the exported Keycloak configuration, and use it to configure the Keycloak. Please refer to Keycloak import documentation for more information.
You need to modify Keycloak standalone.xml
configuration file, and change the socket binding from:
<socket-binding name="https" port="${jboss.https.port:8443}"/>
to
<socket-binding name="https" port="${jboss.https.port:8440}"/>
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:
curl -i -X POST http://localhost:8001/services \ --data "name=openid-connect" \ --data "url=https://httpbin.konghq.com/anything"
-
Create a route:
curl -i -X POST http://localhost:8001/services/openid-connect/routes \ --data "name=openid-connect" \ --data "paths[]=/"
Set up session authentication
The following examples are built with simplicity in mind, and are not meant for a production environment. Because
httpbin.konghq.com
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.
Using the Keycloak and Kong Gateway configuration from the prerequisites, set up an instance of the OpenID Connect plugin with session authentication.
For the demo, we’re going to set up the following:
- Issuer, client ID, and client auth: settings that connect the plugin to your IdP (in this case, the sample Keycloak app).
- Auth method: you only need session auth for this flow. For the purposes of the demo, the example also enables the password grant.
With all of the above in mind, let’s test out session authentication with Keycloak.
Enable the OpenID Connect plugin on the openid-connect
service:
Test the session authentication
- Request the service with basic authentication credentials (created in the Keycloak configuration step),
and store the session:
curl --user john:doe http://localhost:8000 \ --cookie-jar example-user
The cookie should look like this:
HTTP/1.1 200 OK Set-Cookie: session=<session-cookie>; Path=/; SameSite=Lax; HttpOnly
- Make request with a stored session cookie:
curl http://localhost:8000 --cookie example-user
You should get an HTTP 200 response, and the cookie should appear in the request header:
GET / HTTP/1.1 Cookie: session=<session-cookie>
Note: If you want to disable session creation with some grants, you can use the
config.disable_session
configuration parameter.
More information
Session authentication is also compatible with certificate-bound access tokens. In that case, it must be used along with one of the other supported auth methods.