v145 · Web APIs · Session Binding
Session Binding
How DBSC binds sessions to devices, the periodic refresh challenge, what happens in various theft and device-change scenarios, and server-side implementation requirements.
live backend probe
Inspect the current DBSC demo session on this origin, then call the protected resource to see whether the backend accepts the short-lived cookie or returns a refresh challenge.
Use DBSC Live Handshake to register a session, then return here to inspect binding state.
theft and device-change scenarios
| Scenario | DBSC outcome | Why |
|---|---|---|
| Normal use on registered device | Session continues | Periodic refresh succeeds — device private key present |
| Cookie stolen, used on attacker device | Session invalidated | Refresh challenge fails — attacker has no device private key |
| Cookie stolen before first refresh | Short window of risk | Short-lived session token expires quickly (minutes); attacker can use it only until expiry |
| User replaces device / reinstalls Chrome | Session ends — must re-authenticate | Private key lost; refresh fails; user logs in again; new device key registered |
| User clears browser data | Session ends | Private key deleted with browser data |
| Non-DBSC browser (Firefox, Safari) uses same site | Normal session (no DBSC protection) | Server falls back to standard cookie-only session if DBSC not supported |
server implementation checklist
// 1. On login response: issue long-lived cookie + Secure-Session-Registration
// Cookie Max-Age: 300 (5 minutes) — expires quickly if stolen
// Secure-Session-Registration: algorithms + path + challenge + optional authorization
// 2. Verify the registration proof:
// - Parse the dbsc+jwt from Secure-Session-Response
// - Extract device public key from JWT header
// - Verify signature over challenge using the public key
// - Store device public key with the user's session record
// 3. Periodically challenge the browser:
// - Issue short-lived session tokens (minutes, not hours)
// - Include Secure-Session-Challenge on session expiry responses
// 4. Verify refresh proofs:
// - Parse Secure-Session-Response JWT
// - Verify signature using stored device public key
// - Issue new short-lived session if valid
// - Revoke session if invalid (key mismatch = stolen cookie elsewhere)
// 5. Graceful fallback for non-DBSC browsers:
// - If no registration proof received, issue standard long-lived session
// - DBSC is additive — standard session security still applies