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

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. 

• Client Secret (RFC 6749 Section 2.3.1)
• Mutual TLS (RFC 8705)
• Private Key JWT (RFC 7521, RFC 7521, OpenID)

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. 

• token

  • Authorization Code Flow
  • Password Grant
  • Refresh Token Grant

• introspection

  • Introspection Authentication flow

• revocation

  • Session Authentication

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.

Setup

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

Prerequisites

• 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.