Bound to the device
A key the browser keeps
The session is tied to a private key that stays on the device. A cookie copied without that key cannot be refreshed.
Features / Session security
Device Bound Session Credentials (DBSC)
A stolen session cookie lets an attacker skip the password, the passkey and the MFA prompt. With Device Bound Session Credentials, WebFrolic binds each session to a private key kept on the user’s device, so a cookie copied to another machine stops working. The protection extends to your own applications built with the WebFrolic OAuth2 SDK.
Available now in WebFrolic.
Why it matters
Session theft skips every sign-in control you have.
Infostealer malware and malicious browser extensions take session cookies after sign-in, when phishing-resistant authentication has already done its job. Binding the session to the device makes the stolen cookie itself worthless anywhere but the device it came from.
One switch
Configuration → General → Advanced
Administrators turn on DBSC for the identity provider. Browsers that do not support it keep working with standard sessions.
Beyond the IdP
OAuth2 SDK applications
Applications that integrate the WebFrolic OAuth2 SDK get device-bound sessions too, not only the WebFrolic sign-in pages.
The building blocks
Layered with the session controls you already use.
Session security
Continuous identity
Session fingerprinting, active-session limits and network rules still apply. DBSC adds proof of the device to each refresh.
Explore ↗Token security
DPoP tokens
DBSC protects browser sessions. DPoP gives OAuth2 access and refresh tokens the same kind of binding to a key.
Explore ↗Authentication
Phishing-resistant sign-in
Passkeys and security keys protect the sign-in itself. DBSC protects the session that sign-in creates.
Explore ↗Visibility
Session visibility
See active sessions and revoke them when a device is lost or a signal looks wrong.
Explore ↗Enable DBSC
In Configuration → General → Advanced, turn on Device Bound Session Credentials.
Update SDK applications
For your own applications, use a version of the WebFrolic OAuth2 SDK with DBSC support so their sessions are bound too.
Test the replay case
Copy a session cookie to another browser and confirm that it stops working once the short-lived cookie expires.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- Find out which browsers your users run. Other browsers keep standard sessions, so keep your other session controls in place.
- Decide which populations to test first, such as administrators and privileged roles.
- List the applications built on the WebFrolic OAuth2 SDK and plan their SDK upgrade.
- Check that proxies or gateways in front of WebFrolic pass the DBSC refresh requests through.
- Keep session lifetimes, step-up for sensitive actions and revocation in place. DBSC adds to them; it does not replace them.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.