Mutual TLS Sender Constrained Access Tokens

Bearer Tokens

One of the main vulnerabilities of OAuth are 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 legit 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 Tokens.

Mutual TLS Sender Constrained Tokens

Mutual TLS Sender Constrained 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 the 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 Tokens 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 proof to be the holder of the private key of the certificate that the token is bound to.

1. The client holds the private key for the client certificate. The client and server establish a mutual TLS session.
2. The authorization server takes the client certificate from the TLS session and authenticates the client according to the OAuth 2.0 Mutual TLS Client Authentication.
3. The authorization server includes the certificate thumbprint in the access token and returns it to the client.
4. The client and API establish a mutual TLS session. The client uses the same certificate and private key as it did during step 1.
5. The API takes the client certificate from the TLS session and checks if the thumbprint matches the one in the token.

Conclusion

Mutual TLS Client Authentication and Mutual TLS Sender Constrained Tokens together are suitable implementations for environments with high security requirements such as Financial Grade APIs. 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 client obtains a constrained token through the Client Credentials flow for Server-to-Server communication and misbehaves by sending the constrained token to the browser (JavaScript), the API will refuse the request from the JavaScript since the browser will not have the client's private key and certificate for the mutual TLS session.