February 19, 2024
4 min read

Adopt a Zero Trust Approach with OAuth 2.0 Mutual TLS Client Authentication

Veena Rajarathna
Staff Product Manager, Kong
Samuele Illuminati
Software Engineer, 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-based approach, client applications must obtain an access token to access the protected resource. API gateways not only mediate between client & backend services, they can also communicate with the authorization server and obtain an access token on behalf of the client applications (see below).

Authorization server basics

The services of an authorization server, such as token service and introspection service, are usually protected. To obtain a token, the clients will need to authenticate themselves to the authorization server. Client authentication is a way for authorization servers to identify the client and either allow or prevent them from obtaining an access token.

Authorization servers support many ways of client authentication as listed below. 

The preferred choice depends on a few factors, such as the security requirements of the organization and the client type (public or confidential). When registering an OAuth2.0 client with the authorization server, the client authentication method is specified, which defines the client_secret (aka the client password) and the method of including the secret in the request to the token service.

TLS for OAuth client authentication

This method of client authentication uses X.509 client certificates as client credentials. Utilizing TLS certificates for client authentication provides better security characteristics than a shared secrets method. Mutual TLS (mTLS) is often used in this flow so that both the client and the authorization server can verify each other. mTLS is often used in a zero trust security framework. For environments with elevated security needs or those that need to adhere to zero trust principals, an mTLS-based solution becomes mandatory.

TLS client authentication support in Kong 

Kong supports all OAuth2.0 and OpenID connect (OIDC) flows via the OIDC plugin. With the Kong Gateway Enterprise 3.6 release, the OIDC plugin supports TLS Client Authentication as one of the authentication methods for the following endpoints in corresponding flows. 

In the flows listed above, when the plugin is configured to use TLS Client Authentication, Kong establishes or reestablishes a mTLS connection to the authorization server (IdP) using the specified client certificate (figure 2). Kong also includes the client_id in all of the requests to the authorization server. The token is granted by the token service once the authorization server verifies Kong's certificate. Kong can also be configured to optionally verify the server certificate to achieve end-to-end mTLS.


Configuring Kong to use mTLS connection to Authorization Server

In this example, we'll configure an Authorization Code Grant Flow. As a refresher, the auth code grant flow is a three-legged authorization flow where Kong exchanges the code for an access token. We will configure Kong to use TLS or mTLS when accessing the authorization server’s token endpoint to obtain a token.

High-level workflow

  1. Set up Kong and the authorization server to verify each other’s certificate
  2. Create a confidential client in the authorization server and configure it to expect TLS authentication
  3. Configure Kong for authorization code grant flow and set it to use TLS client authentication


  • Generate CA and client certificates with a CN (example CN=kong) and key

Authorization server setup 

This may vary by the IdP, but at a high level the following must exist:

  • Configure authorization server with root CA certificates (created above) to verify the incoming client certs
  • Create a client application as follows

    • grant type : Authorization Code 
    • response type : Code. 
    • Client authentication : tls client authentication 

      • subject identifier (CN) : cn=kong

Kong setup

Configure Kong with the following

  • Upload the CA certificate (created above). This will be used to verify the authorization server certificate
  • Upload Kong’s client certificate and key. Kong will use this certificate to establish mTLS connection to authorization server 
  • Create a Service/Route 
  • Configure OIDC plugin (either on service/route or global)

    • Set auth method : authorization code flow
    • Client_id : <client_id from 2.a>
    • Issuer : <well known endpoint>
    • Set token authentication method :  tls client authentication

Below is a sample OIDC plugin config sample showing only the relevant fields.

With this setup in place, when a client application tries to access a protected resource, Kong will redirect the client to log in with user credentials.

Upon successful login, Kong exchanges the code for a token. In order to obtain the token, Kong uses its client cert to make a request to the token endpoint. The authorization server validates the client certificate and returns the token. Once the token is obtained, Kong proxies the request for the protected resource. 

The following screenshots show a sample exchange during an authorization code flow.

The token is granted by the token service once the authorization server verifies Kong’s certificate. Kong will proxy the request to the backend API service. 


API gateways not only centralize API traffic, they can also securely fetch access tokens on behalf of confidential client applications.

For environments with elevated security needs or those that need to adhere to zero trust principals, an mTL- based solution becomes mandatory. By supporting mTLS-based client authentication, Kong enables customers to adopt or adhere to zero trust principals.

Ready to dive in? Get started with Kong Konnect for free.