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 |
---|---|
|
|
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.