Mutual TLS Sender Constrained Access Tokens
On this page
Mutual TLS Sender Constrained Access Tokens provide a robust method for enhancing the security of OAuth 2.0-based authorization by binding the access token to the client's TLS certificate. This prevents unauthorized use of access tokens even if they are leaked or intercepted. In this article, we explain how they work, why they matter, and how to implement them effectively in secure systems.
Bearer Tokens
One of the main vulnerabilities of OAuth is the use of bearer tokens. Presenting a valid bearer token is proof enough for gaining access. That means that if a bearer token gets into the hands of unauthorized actors, they can impersonate the user and get unauthorized access to the protected resources. The resource server cannot determine if the sender of a bearer token is legitimate or not as long as the token is valid.
A solution to this problem are Holder-of-Key Tokens or Proof-of-Possession Tokens where the resource server can verify that the sender of a token is the same entity whom the token was issued for. Certificate-bound access tokens are an example of such tokens, and we refer to them as Mutual TLS Sender Constrained Access Tokens.
Mutual TLS Sender Constrained Access Tokens
Mutual TLS Sender Constrained Access Tokens are tokens that are bound to the underlying mutual TLS connection between the client and the authorization server. The TLS session is established by Mutual TLS Client Authentication as part of a OAuth 2.0 workflow. After a successful client authentication, the authorization server will encode the thumbprint (hash) of the client certificate either directly in the token (JWT) or in the Introspection Response (when using opaque tokens).
The following figure shows an example of a Certificate-Bound Access Token. The token includes the certificate thumbprint in the confirmation claim cnf.
{"sub": "testuser","purpose": "access_token","iss": "https://idsvr.example.org/oauth/anonymous","active": true,"token_type": "bearer","client_id": "mutual_tls_client","aud": "mutual_tls_client","nbf": 1542896887,"scope": "","cnf": {"x5t#S256": "FjeHcvJwiHXlr8dgnP7UvLQ7dLLMTe_3SgMYMuEpekc"},"exp": 1542897187,"delegationId": "d0d2bc6b-55f9-4412-83bc-a42b992e15c1","iat": 1542896887}
When the client requests the protected resources at the resource server (API) with a Mutual TLS Sender Constrained Access Token, it will be forced to establish a mutual TLS session. The client presents the same certificate that it used to authenticate to the authorization server. The API can then check if the client certificate from the TLS session matches the one in the token by comparing the thumbprint. If the client can establish a TLS session successfully and the token refers to the client certificate used in that session, the client is in possession of the private key belonging to the client certificate and authorized to use the access token. The token itself will not be enough as the sending entity must also prove it is the holder of the private key of the certificate that the token is bound to.
How to Implement Mutual TLS Sender Constrained Access Tokens
- The client holds the private key for the client certificate. The client and server establish a mutual TLS session.
- The authorization server uses OAuth 2.0 Mutual TLS Client Authentication to authenticate the client based on the certificate.
- The authorization server includes the certificate thumbprint in the access token and returns it to the client.
- The client and API establish a mutual TLS session. The client uses the same certificate and private key as it did during step 1.
- The API takes the client certificate from the TLS session and checks if the thumbprint matches the one in the token.
Benefits of Mutual TLS Sender Constrained Access Tokens
Mutual TLS sender-constrained access tokens mitigate the risk of token replay and man-in-the-middle attacks because they require the client to demonstrate possession of the private key during every API request. They are especially useful for:
- Securing Financial-grade APIs (FAPI)
- Server-to-server communication using the Client Credentials grant
- Preventing misuse of access tokens in browser-based environments
- Enforcing certificate pinning and token binding
Code Example
The Mutual TLS Code Example provides an example end-to-end flow, for a B2B use case, where one organization calls another with mutual TLS and certificate-bound access tokens. You can run the code example on a local computer to see sender-constrained access tokens in action.
Conclusion
Mutual TLS sender-constrained tokens add another security layer by requiring proof of possession of the token sender and mitigate the risk of misuse of tokens, as sender-constrained tokens simply cannot be replayed or redirected by or to an unauthorized party. In particular, if a third-party client fails to take care to protect access tokens that it receives for your organization's APIs, and a malicious actor attempts to call your API, the API will refuse the request since the caller does not have the client's private key and certificate for the mutual TLS session.
Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
