Device Bound Session Credentials (DBSC)

Stay organized with collections Save and categorize content based on your preferences.

Device Bound Session Credentials (DBSC) strengthen authentication by adding hardware-backed session security.

Daniel Rubery

José Luis Zapata

Introduction

Many websites rely on long-lived cookies for user authentication, but these are susceptible to session hijacking. Device Bound Session Credentials (DBSC) adds a layer of hardware-backed security to mitigate this risk, ensuring sessions are bound to specific devices.

This guide is intended for developers who maintain authentication flows in web applications. It explains how DBSC works and how to integrate it into your site.

How DBSC works

At a high level, DBSC introduces a cryptographic key pair associated with the user's device. Chrome generates this key pair during login and stores the private key in secure hardware, such as a Trusted Platform Module (TPM), when available. Sessions use short-lived cookies. When one of these cookies expires, Chrome proves possession of the private key before refreshing them. This process links session continuity to the original device.

If a user's device does not support secure key storage, DBSC gracefully falls back to standard behavior without breaking the authentication flow.

Implementation overview

To integrate DBSC into your application, you need to make the following changes:

• Modify your login flow to include a Sec-Session-Registration header.
• Add a session registration endpoint that:
  • Associates a public key with the user's session.
  • Serves session configuration.
  • Transitions to short-lived cookies.
• Add a refresh endpoint to handle cookie renewal and key possession validation.

Most of your existing endpoints don't require any changes. DBSC is designed to be additive and non-disruptive.

When a required short-lived cookie is missing or expired, Chrome pauses the request and tries to refresh the cookie. This lets your app keep using its usual session cookie checks to confirm the user is signed in. Since this matches typical authentication flows, DBSC works with minimal changes to your login logic.

Implementation steps

This section walks through the necessary changes to your authentication system, including how to modify your login flow, handle session registration, and manage short-lived cookie refreshes. Each step is designed to integrate smoothly with your existing infrastructure.

The implementation steps follow the common flow a signed-in user would experience when DBSC is active: registration at login, followed by regular short-lived cookie refreshes. You can test and implement each step independently, depending on your app's level of session sensitivity.

1. Modify login flow

After the user logs in, respond with a long-lived cookie and a Sec-Session-Registration header. For example:

The following HTTP response header is returned after successful session registration:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

If the device supports secure key storage, Chrome contacts the /StartSession endpoint with a public key in a JSON Web Token (JWT).

The auth_cookie in this example represents your session token. You can name this cookie whatever you like, as long as it matches the name field in your session configuration and is used consistently throughout your application.

2. Implement the session registration endpoint

At /StartSession, your server should:

• Associate the received public key with the user's session.
• Respond with a session configuration.
• Replace the long-lived cookie with a short-lived one.

In the following example, the short-lived cookie is configured to expire after 10 minutes:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implement the refresh endpoint

When the short-lived cookie expires, Chrome initiates a refresh flow to prove possession of the private key. This process involves coordinated actions by both Chrome and your server:

1. Chrome defers the user's request to your application and sends a refresh request to /RefreshEndpoint:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. Your server responds with a challenge:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome signs the challenge using the stored private key and retries the request:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. Your server validates the signed proof and issues a refreshed short-lived cookie:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome receives the refreshed cookie and resumes the original deferred request.

Alternative integration pattern

To improve resilience, sites can add a second, non-DBSC cookie alongside the short-lived cookie. This long-lived cookie is used only to issue new short-lived tokens and helps distinguish between truly unauthenticated requests and temporary DBSC failures.

• The long-lived cookie persists even if DBSC fails.
• The short-lived cookie is refreshed using DBSC and required for sensitive operations.

This pattern gives sites more control over how to handle edge cases.

Caveats and fallback behavior

Chrome may skip DBSC operations and send requests without the DBSC-managed short-lived cookie in the following scenarios:

• The refresh endpoint is unreachable due to network errors or server issues.
• The TPM is busy or encounters signing errors. Because the TPM is shared across system processes, excessive refreshes may exceed its rate limits.
• The DBSC-managed short-lived cookie is a third-party cookie, and the user has blocked third-party cookies in their browser settings.

In these situations, Chrome falls back to using the long-lived cookie if one is still present. This fallback only works if your implementation includes both a long-lived and a short-lived cookie. If not, Chrome sends the request without a cookie.

Summary

Device Bound Session Credentials improve session security with minimal changes to your application. They provide stronger protections against session hijacking by tying sessions to specific devices. Most users benefit without experiencing any disruption, and DBSC falls back gracefully on unsupported hardware.

For more information, refer to the DBSC specification.