Token Binding

Definition

Bearer tokens have a fundamental weakness: whoever has the token can use it. If an attacker steals your access token through a network attack, malware, or a compromised server, they can impersonate you until that token expires. Token Binding was developed to solve this problem by cryptographically tying tokens to the specific TLS connection they were issued for.

The concept is elegant: when you establish a secure TLS connection, your browser generates a unique cryptographic key pair just for that connection. When you request an access token, that token gets “bound” to your key pair. Later, when you use the token, you must prove you possess the private key. An attacker who intercepts your token cannot use it because they do not have your private key - the token is effectively useless without it.

It is important to note that Token Binding specification development has largely stalled, and browser support remains limited. The industry has moved toward a simpler alternative called DPoP (Demonstrating Proof-of-Possession), which achieves similar goals with better ecosystem support. DPoP creates a signed proof that accompanies each token use, proving you still control the keys. If you are implementing proof-of-possession tokens today, DPoP is usually the recommended path.

Example

High-security banking applications: Financial institutions exploring token binding wanted to ensure that even if malware on a user’s computer captured their access token, that token could not be used from a different machine. The token only works with the original TLS connection’s keys.

Enterprise SSO systems: Companies handling sensitive data considered token binding to prevent token theft attacks. Even if an attacker intercepted a session cookie, they could not replay it from their own browser.

Government systems: High-assurance government applications looked at token binding to meet strict security requirements where regular bearer tokens were insufficient.

Mobile banking apps: Financial apps explored cryptographically binding tokens to the specific device, so stolen tokens could not be used on attacker devices.

Analogy

The Fingerprint-Linked Wristband: Imagine a water park wristband that is not just a band but is electronically paired to your fingerprint. Even if someone steals your wristband, it will not work for them - the entry gates check both the wristband AND your fingerprint. Token binding pairs the token with cryptographic proof only you possess.

The Key Card and Fingerprint Scanner: Some high-security buildings require both a key card AND a fingerprint scan. Having just the key card is not enough - you need to prove you are the authorized holder. Token binding adds this second factor to bearer tokens.

The Two-Part Lock: Some bank vaults require two keys held by different people. Neither key alone can open the vault. Token binding requires both the token AND proof of key possession - neither alone grants access.

The Personalized Concert Ticket: Imagine concert tickets that only work when scanned alongside your ID photo that was taken when you bought them. Scalped tickets would not work for someone else. Bound tokens only work for their original holder.

Code Example

// Token Binding conceptual flow (low-level implementation)
// Note: Token Binding is not widely implemented and has limited browser support

// Client generates token binding key pair during TLS handshake
const tokenBindingKeyPair = await crypto.subtle.generateKey(
  {
    name: 'ECDSA',
    namedCurve: 'P-256'
  },
  true,
  ['sign', 'verify']
);

// Client creates Token Binding message
const tokenBindingMessage = {
  tokenBindingType: 'provided',
  keyParameters: 'ecdsap256',
  signature: await signTokenBinding(tokenBindingKeyPair, tlsExporter)
};

// Include Token Binding ID in token request
const tokenRequest = await fetch('https://oauth.provider.com/token', {
  headers: {
    'Sec-Token-Binding': base64encode(tokenBindingMessage)
  },
  // ... other token request parameters
});

// Server binds token to Token Binding ID
// Token includes 'cnf' (confirmation) claim with Token Binding ID

// When using token, client must prove possession of private key
// Server validates signature matches Token Binding ID in token

// DPoP (Demonstrating Proof-of-Possession) is modern alternative:
const dpopProof = await generateDPoPProof({
  htm: 'GET',
  htu: 'https://api.example.com/resource',
  privateKey: clientPrivateKey
});

fetch('https://api.example.com/resource', {
  headers: {
    'Authorization': `DPoP ${accessToken}`,
    'DPoP': dpopProof
  }
});

Diagram

sequenceDiagram
    participant Client
    participant TLS as TLS Layer
    participant AuthServer as Auth Server
    participant API
    participant Attacker

    Note over Client,TLS: TLS Handshake
    Client->>TLS: 1. Establish TLS connection
    TLS->>Client: 2. Generate unique key pair for this connection

    Note over Client: Token bound to TLS connection keys

    Client->>AuthServer: 3. Request token + Token Binding proof
    AuthServer->>Client: 4. Token with binding (cnf claim)

    Client->>API: 5. Request + Token + Proof of key possession
    API->>API: 6. Verify token signature
    API->>API: 7. Verify binding matches TLS connection
    API->>Client: 8. Response OK

    rect rgb(255, 230, 230)
        Note over Attacker: Token Stolen!
        Attacker->>API: 9. Stolen token (different TLS connection)
        API->>API: 10. Token valid BUT binding fails!
        API->>Attacker: 11. 401 Unauthorized
        Note over Attacker: Cannot prove possession of
original TLS connection keys
    end

    Note over Client,API: Token is CRYPTOGRAPHICALLY BOUND
to the original TLS connection

Security Notes

Standards & RFCs