Token Binding is a proposed standard for a Transport Layer Security (TLS) extension that aims to increase TLS security by using cryptographic certificates on both ends of the TLS connection. Current practice often depends on bearer tokens,[1] which may be lost or stolen. Bearer tokens are also vulnerable to man-in-the-middle attacks or replay attacks. In contrast, bound tokens are established by a user agent that generates a private-public key pair per target server, providing the public key to the server, and thereafter proving possession of the corresponding private key on every TLS connection to the server.
Token Binding is an evolution of the Transport Layer Security Channel ID (previously known as Transport Layer Security – Origin Bound Certificates (TLS-OBC)) extension.
Industry participation is widespread with standards contributors including Microsoft,[2] Google,[3] PayPal, Ping Identity, and Yubico. Browser support remains limited, however. Only Microsoft Edge has support for token binding.[4]
IETF standards
The following group of IETF RFCs and Internet Drafts comprise a set of interrelated specifications for implementing different aspects of the Token Binding standard.
- The Token Binding Protocol Version 1.0.[5] Allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.
- Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation.[6] Extension for the negotiation of Token Binding protocol version and key parameters.
- Token Binding over HTTP.[7] A collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.
- Token Binding for Transport Layer Security (TLS) Version 1.3 Connections.[8] This companion document defines a backwards compatible way to negotiate Token Binding on TLS 1.3 connections.
- HTTPS Token Binding with TLS Terminating Reverse Proxies.[9] Defines HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. This facilitates the reverse proxy and backend server functioning together as though they are a single logical server side deployment of HTTPS Token Binding.
Related IETF draft standard:
- OAuth 2.0 Token Binding.[10] Enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks.