Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens) for web applications to access protected resources. Any party in possession of such token, gains access to the protected resource. Attackers export bearer tokens from the user's machine, present them to web services, and impersonate authenticated users.

The idea of Token Binding is to prevent such attacks by cryptographically binding security tokens to the TLS layer.

Token Binding: A TLS Token Binding is established by the user agent generating a private-public key pair (possibly within a secure hardware module) per target server, and proving possession of the private key on every TLS connection to the target server. The proof of possession involves signing the exported keying material for the TLS connection with the private key. Such TLS Token Binding is identified by the corresponding public key.

When issuing a security token to a client that supports TLS Token Binding, a server includes the client's TLS Token Binding ID in the token. Later on, when a client presents a security token containing a TLS Token Binding ID, the server makes sure the ID in the token matches the ID of the TLS Token Binding established with the client. In the case of a mismatch, the server discards the token.

Security Considerations

• Token Binding private keys are high-value assets and should be strongly protected, ideally by generating them in a hardware security module which prevents key export.
• Clients must Use different Token Binding Ids for different eTLDs to Protects against cross-domain linking of user identities.
• To protect privacy, TLS Token Binding IDs are never transmitted in clear text and can be reset by the user at any time, e.g. when clearing browser cookies. Some applications offer special privacy modes where they don't store or use tokens supplied by the server, e.g. "in private" browsing. Connections made in these special privacy modes SHOULD NOT negotiate Token Binding.