Device Bound Session Credentials (DBSC) strengthen authentication by adding
hardware-backed session security.
 Daniel Rubery  José Luis Zapata [GitHub](https://github.com/zapata131) [LinkedIn](https://www.linkedin.com/in/zapata131) [Bluesky](https://bsky.app/profile/zapata131.bsky.social) [Homepage](https://www.zapata131.com)
## 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)](https://en.wikipedia.org/wiki/Trusted_Platform_Module),
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 `Secure-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
`Secure-Session-Registration` header. For example:
The following HTTP response header is returned after successful session
registration:
HTTP/1.1 200 OK
Secure-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 minutes Set-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"
}]
}
> [!NOTE]
> **Note:** DBSC only applies to HTTPS pages. It does not support Partitioned cookies. While DBSC does not require the `Secure` attribute on cookies, HTTP requests are not protected by DBSC.
### 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-Secure-Session-Id: session_id
2. Your server responds with a challenge:
HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"
3. Chrome signs the challenge using the stored private key and retries the
request:
POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-Session-Response:
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.
> [!CAUTION]
> **Caution:** If malware is present on the device during session registration, it may be able to extract the private key. This could enable session hijacking similar to other styles of cookie theft. However, attacks involving malware during registration or TPM driver modification are considered significantly more complex and detectable than standard attacks.
## 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](https://w3c.github.io/webappsec-dbsc/).