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).
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.
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.
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
introspection
revocation
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.
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.
This may vary by the IdP, but at a high level the following must exist:
Create a client application as follows
Client authentication : tls client authentication
Configure Kong with the following
Configure OIDC plugin (either on service/route or global)
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.
Ensuring secure access to applications and APIs is critical. As organizations increasingly adopt microservices architectures and cloud native solutions, the need for robust, fine-grained access control mechanisms becomes paramount. This is where the
With digital transformation shifting networks into the cloud — from remote workforces to online banking — cyberattacks are growing more prevalent and sophisticated. Legacy security models like VPNs and perimeter-based firewalls are proving inadequat
With its flexible querying capabilities, GraphQL makes it easy to combine data from multiple sources into a single endpoint. GraphQL and API management go hand in hand to build next-generation API platforms. However, GraphQL's features can als
When it comes to digital identity, OpenID and OAuth are two peas in a pod, but they have their differences. OpenID connects you to relying parties using a single sign-on, while OAuth grants access tokens so you can give apps limited access. They bo
As APIs and microservices evolve, the architecture used to secure these resources must also mature. Utilizing a token-based architecture to protect APIs is a robust, secure and scalable approach, and it is also much safer than API keys or basic au
As more and more companies move to a multi-cloud strategy and increase usage of a cloud native infrastructure , API providers are under a lot of pressure to deliver APIs at scale in multi-cloud environments. At the same time, APIs should follow eac