DBSC
DBSC binds a session cookie to a private key generated in the device’s TPM or Secure Enclave, so even if the cookie is stolen, the session cannot be used on another device.
- If the DBSC state is stored together with the regular session blob, a race condition can cause the binding to disappear and silently downgrade authentication to a regular bearer-cookie model.
- During refresh, the cookie and challenge must be rotated every time. Because of real network latency, the system also needs overlap handling that briefly accepts the previous cookie. A bug that did not appear on localhost caused random logouts in production.
/dbsc/refreshmust return 401 because a 302 redirect can cause a Chrome tab to hang indefinitely.
- A challenge mismatch is not necessarily an attack; it can normally occur because of concurrent refreshes or retries. If the signature is valid, do not revoke the session. Instead, issue a new challenge and retry.
- In SAML/SSO flows, the initial DBSC registration POST can be sent without authentication because of
SameSite=Lax, so binding should happen on the next same-site navigation.

Seonglae Cho