v147 · Security · Credentials
DBSC Session Binding Flow
Animated step-through of the Device-Bound Session Credentials registration and refresh flow — from keypair generation to signed proof-of-possession — showing exactly why a stolen cookie cannot be replayed without the device's private key.
User logs in → server sets session cookie
Server issues a standard session cookie. Also signals DBSC support via Sec-Session-Registration response header.
Sec-Session-Registration: (ES256);path="/";challenge="ch_A3FxzQ"
Browser generates a hardware-backed keypair
Chrome creates an EC P-256 keypair in the platform's secure enclave (TPM / Secure Enclave). The private key never leaves the device.
Public key: MFkwEwYHKoZI... (exported)
Private key: [sealed in TPM — not exportable]
Browser sends signed registration request
POSTs to the server's registration endpoint with a JWT signed by the new private key, proving possession.
Cookie: session=abc123
Body: {
"alg": "ES256",
"pub_key": "MFkwEwYHKoZI...",
"signed_challenge": "eyJhbGciOiJFUzI1NiJ9.eyJjaGFsIjoiY2hfQTNGeHpRIn0.[sig]"
}
Server stores public key → binding established
Server saves the public key linked to this session. Future requests must carry a valid proof-of-possession signed by the matching private key.
DB: sessions["abc123"].bound = true
Response: 200 OK — binding confirmed
Every subsequent request carries a signed token
Chrome adds a Sec-Session-Response header with a fresh JWS, signed by the private key, for each credentialled request.
Cookie: session=abc123
Sec-Session-Response: eyJhbGciOiJFUzI1NiJ9.eyJpYXQiOjE3NDk2OTkyMDB9.[fresh-sig]
Server verifies signature — grants or denies access
Server verifies the JWS against the stored public key. If verification fails (wrong device, no sig), the session is invalid even with a valid cookie.
Access granted to /api/user
If cookie stolen & replayed from another device:
Sec-Session-Response: [missing or wrong sig]
Verify: → ✗ FAIL — session invalidated
attack resistance comparison
Cookie theft (traditional session)
Attacker exfiltrates the session cookie via XSS or network interception.
Cookie replayed from attacker's machine. Server accepts it — no device proof required.
Cookie theft (DBSC session)
Attacker exfiltrates the session cookie. They do NOT have the device's private key.
Request arrives without a valid
Sec-Session-Response. Server rejects it — cookie alone is insufficient.Token theft (traditional bearer)
Attacker steals a long-lived bearer token from localStorage.
Token replayed until expiry. No device binding to invalidate it.
Malware on the same device
Malware has full access to the device — including the TPM.
references
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗