In token-based architecture, tokens represent the client’s entitlement to access protected resources. Access tokens (or bearer tokens as they're commonly known) are issued by authorization servers after successful user authentication. The tokens are passed as credentials in the request to the target APIs which inform the API that the bearer of the token is authorized to access the API and perform certain actions.
In the flows where access tokens grant access to protected resources, the legitimacy of the token bearer is assumed. Access is granted based on the validity of the token. There is no validation that the bearer is in fact the legitimate owner of the token. This is one of the main vulnerabilities of a bearer token.
If the tokens fall into the hands of bad actors, they can be misused. With the stolen or leaked tokens, bad actors can easily impersonate the user and obtain unauthorized access to protected resources.
For any average API provider, this is a major concern. Recently, Sourcegraph experienced a security [incident](https://about.sourcegraph.com/blog/security-update-august-2023)incident with leaked admin tokens. The malicious users used their privileges to increase API rate limits for a small number of users. For environments with heightened security needs, stolen or leaked tokens are a serious security risk.
A solution to this problem is constraining the tokens issued by authorization server to clients (**sender-constrained tokens)** so only the entity/client to whom a token was issued can use the token to access resources. This approach is also known as **holder of key** or **proof of possession **tokens.
The client presenting the access token has to prove that they are authorized to use the token. To achieve this, the authorization servers bind the tokens to the client's cryptographic keys. Resource servers can then validate the clients are in possession of those keys and grant/deny access accordingly.
The primary security vulnerability of standard bearer tokens is remediated, as the legitimacy of the bearer is verified. Access to the protected resource is granted after successful validation of
For environments with high security requirements such as financial services, e-health, and e-gov, this added layer of token security mitigates the risk of misuse of tokens as sender-constrained tokens simply cannot be replayed or redirected by an unauthorized party.
Moreover, usage of sender-constrained tokens is a must in open banking. One of the requirements of financial API (FAPI [2.0](https://openid.net/specs/fapi-2_0-security-02.html#name-requirements-for-resource-s:~:text=5.3.3.-,Requirements%20for%20Resource%20Servers,-The%20FAPI%202.0)2.0) is for the resource servers to support and verify sender-constrained access tokens using either of the methods.
The [RFC ](https://datatracker.ietf.org/doc/html/rfc8705)RFC describes two methods to implement sender-constrained tokens
With mTLS, the access tokens are bound to the underlying mutual TLS connection between the client and the authorization server. Such tokens are known as **certificate-bound access tokens**. This approach uses the Public Key Infrastructure (PKI). The CA is trusted by the Authorization server and Kong.
Figure 1 shows a sample exchange between the client, IDP, and Kong. In a request to obtain a token, the client establishes a mutual TLS session with the authorization server’s token endpoint. After a successful TLS client authentication, the authorization server will mint an access token, encode the thumbprint of (hash) the client certificate either directly in the token (JWT) or in the Introspection Response (when using opaque tokens).
To access resources protected by Kong, the client establishes a TLS connection to Kong Gateway using the same client certificate and presents the access token. The same CA is trusted by Kong as well. Kong validates the client certificate and the certificate thumbprint in the tokens to the underlying mTLS connection. Access to the protected resource is granted after successful validation of all three.
To support certificate-bound tokens there are requirements on all parties involved in a typical token-based flow. Following are the prerequisites for each party involved in the flow
Kong can be instructed to handle certificate-bound access tokens with the help of two plugins:
`OIDC` plugin`TLS modifier` or `mtls-auth``TLS Modifier plugin` does not enforce a mTLS connection. However, for certificate-bound access tokens to work, a client certificate must be presented along with the token
`mtls-auth` The CN check/validation cannot be disabled in the plugin and hence the plugin requires consumer mapping. Consumer objects should be created and client certificates need to be mapped.
Kong supports the usage of certificate-bound access tokens in three authentication flows. In these flows, the client entity obtains an access token from the authorization server's token endpoint and presents that as a bearer in the request to Kong. If the access token is opaque, Kong exchanges it for a JWT by calling the introspection endpoint.
OIDC plugin offers two new settings to control the behavior of the plugin for certificate-bound tokens.
proof_of_possession_mtls = strict | optional | off (default: off)
proof_of_possession_auth_methods_validation = on | off (default: on)
With all the prerequisites met and the plugins configured to support certificate-bound tokens, Kong Gateway will enforce the incoming requests to establish a mutual TLS connection using a valid client certificate and present an access token. Kong proxies the request after successful validation of the certificate thumbprint in the token to the client certificate in the underlying connection.
For step-by-step instructions on how to enable the feature refer to [OpenID Connect | Kong Docs](https://docs.konghq.com/hub/kong-inc/openid-connect/#certificate-bound-access-tokens)OpenID Connect | Kong Docs
With this feature, Kong complies with the requirements of financial API (FAPI 2.0) to support and verify sender-constrained access tokens. It's not limited to [open banking](https://konghq.com/solutions/open-banking)open banking or [financial services](https://konghq.com/events/webinars/accelerate-your-financial-services-api-strategy-in-aws-with-kong-konnect)financial services. Mutual TLS Sender-Constrained Tokens are a suitable implementation for any environment with high security requirements such as e-gov and e-health. The solution forces the sender to prove they are the rightful owner of the token. This added layer of security mitigates the risk of misuse of tokens as they cannot be used without proof of possession.
Traditional agreement processes were slow and heavily manual. Documents were often created in office tools, shared through email, printed, signed physically, and stored across multiple systems. Tracking the status of agreements required manual follo
[](https://konghq.com/blog/engineering/automating-agreement-workflows-kong-konnect-and-docusign-for-developers)
How Kong Gateway 3.14 closes the consistency gap in IAM-based authentication across AWS, Azure and GCP — and what it means for your production deployments Starting with 3.13 (which addressed Redis support) and completed in 3.14, Kong now presents
[](https://konghq.com/blog/engineering/cloud-native-authentication)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
Free collaboration with Postman — a myth On March 1st, 2026, Postman discontinued free collaboration for small teams. Now , Git or Cloud-native collaboration requires a Team plan starting at $19 per person per month. That means even a 3-person team
[](https://konghq.com/blog/enterprise/insomnia-vs-postman-evaluating-api-testing-tools)
What are Control Plane Groups? Control Plane Groups in Kong Konnect provide a structured way to manage multiple control planes within a single organization. Think of it as a federated approach: different teams can deploy and manage their own APIs wh
[](https://konghq.com/blog/engineering/kong-konnect-control-plane-groups)
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
[](https://konghq.com/blog/engineering/secure-access-control-with-opa-and-kong)