Skip to content
Connect2id

How to bind user sessions to browser fingerprints

Browser (user agent) fingerprinting collects information from interacting with the web browser for the purpose of remotely identifying the user’s device. Identity providers can use browser fingerprinting to detect new devices and session anomalies (e.g. a hijacked cookie), in order to force user re-authentication.

1. Principle

Connect2id server 18.0 enables an IdP to factor the browser fingerprint in the SSO decision-making. When the server receives a request from a client application in a web-based flow, it is supplied with a computed fingerprint of the browser. If the computed fingerprint matches the stored fpt value of the subject session, the SSO is allowed to proceed (provided all other factors, such as ACR level, allow that). If the two fingerprints don’t match, the server ends the session and triggers a user authentication prompt.

2. Optimal fingerprint inputs

The fingerprint inputs should be relatively stable and include inputs that are difficult to spoof.

Inputs that are stable don’t change with browser restarts and are not affected by transient conditions, such as the current network IP address.

Inputs that are spoof-resistant are hard to manipulate via JavaScript alone.

Recommended fingerprint inputs:

  • Platform / OS
  • Language(s)
  • Hardware concurrency (CPU cores)
  • Low-level rendering (canvas, WebGL, fonts)
  • TLS-client fingerprint

Studies have been made to identify fingerprint inputs that have optimal security properties and are at the same time quick to collect.

Browser fingerprinting is to used judiciously, and typically only on user login and (re)authentication, to avoid violating privacy expectations and laws (GDPR). If required, give notice or obtain user consent.

3. Fingerprint format

The Connect2id server expects the browser fingerprints to be BASE64URL-encoded SHA-256 hashes.

Example fingerprint:

0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I

4. Session binding

A subject session is bound to a browser fingerprint when it’s created. The session fpt value is immutable and cannot be changed during the sessions’s lifetime.

To bind a new session to a computed browser fingerprint, when the authorisation session API comes up with an authentication prompt, submit the usual session details together with the fpt value.

Example:

PUT /authz-sessions/rest/v3/cAjH3ZAonDVFs9u8XZtvuA.L-WFBXv5ompD96ztw0Rr4w HTTP/1.1
Host: c2id.com
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
Content-Type: application/json

{
  "sub" : "alice",
  "fpt" : "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
}

For each received authorisation request, make sure the browser fingerprint is computed and included in the fpt value of the authorisation session start request.

Example start of an authorisation session including a browser fingerprint:

POST /authz-sessions/rest/v3/ HTTP/1.1
Host: c2id.com
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
Content-Type: application/json

{
  "query"   : "response_type=code&scope=openid%2020email&client_id=s6BhdR&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb",
  "sub_sid" : "WYqFXK7Q4HFnJv0hiT3Fgw.-oVkvSXgalUuMQDfEsh1lw",
  "fpt"     : "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
}

If the Connect2id server finds a current subject session, the fingerprint values match and all other SSO criteria are fulfilled, then the user will not be asked to re-authenticate. If the fingerprint has changed, the Connect2id server will end the subject session and return an authentication prompt.

The server suports a gradual migration of sessions to browser fingerprints, or only part of the sessions to be bound to fingerprints. This means that if authorisation session start request includes a fpt value, but the current user session was not created with a fpt, this will not trigger an authentication prompt.

Auth prompt not triggered Auth prompt triggered
  • No fpt in authZ session start request
  • No fpt in current subject session
  • The fpt values of the authZ session start request current subject session match
  • The fpt values of the authZ session start request current subject session don't match

5. Relation to the web SSO eligibility checker

The WebSSOEligibilityChecker SPI enables IdPs to introduced arbitrary additional factors to the SSO decision making. Plugins that were created for the purpose of binding IdP web sessions to browser fingerprints can switch to the new built-in support.