Adaptive Authentication

A login session refers to the period of time during which a user is logged into a system or website. It begins when the user enters their login credentials and ends when they log out or the session expires. During a login session, the user is able to access resources and perform actions that are restricted to logged-in users.

In contrast to traditional IAM solutions, TrustBuilder maintains an evolving lifecycle of a session. Moreover, TrustBuilder maintains the lifecycle server-side and does not need cookies.

Types of sessions

There are several layers where sessions can be created when users log in: 

Service Provider Session

An application, a platform or a Service Provider in general may maintain a session for its users. While such Service Provider uses TrustBuilder to authenticate users, it may also keep track of users that have logged in. For example a regular web application may keep a user session by setting a session cookie in the user’s browser. When the Service Provider keeps a Persistent Cookie, the cookie survives any browser session to give the user the experience of “Keep me logged on”.

Client App Session

A mobile app or a Client App in general may maintain a session to remember a user who signed in to the app by keeping the user’s login in Local Storage, for example in the form of an id token and refresh token. The user can reactivate such ‘session’ using a smartphone’s PIN, face-id or fingerprint.

Identity Provider Session

An identity provider can play 3 roles:

1. provide identity information during registration or to supply Derived Attributes at a later stage

2. provide an external authentication factor

3. provide a token as proof that the user has been authenticated in a federated way.

Identity providers providing high levels of assurance (identity assurance and/or authentiucation assurance) typically do not maintain a session of the user.

In case of social identity providers, such Facebook or Google, a session may be maintained so that when a user already has a valid sign-in, they will not be prompted again to sign in. A social identity provider may maintain a session using a session cookie, a persistent cookie, a token in Local Storage (e.g. SAML or OIDC) or other mechanism.

TrustBuilder Session

While the layers above provide user convenince in a certain context, TrustBuilder also maintains a session on the Authentication Server. This server-side session layer makes the SSO experience possible for inbound SSO implementations.

While cookies may provide convenience, they are vulnerable for so-called man-in-the-middle attacks. This is one of the reasons why TrustBuilder does not set cookies.

Long lived tokens are also vulnerable to token stealing. This is one of the reasons why TrustBuilder reserves long lived tokens, ie. id tokens, for the client app only and they must never leave the client app and be passed around.

Adaptive Authentication

Adaptive authentication typically only requires a second factor of authentication when it is deemed necessary, based on the level of risk associated with a login attempt. For example, if a user is logging in from a known location, using a device that has been previously used to access the account, and at a time when the user would typically be accessing the account, the login attempt may be considered low-risk and only a single factor (e.g. a password) may be required.

However, if the login attempt is from an unknown location, from an unknown device, or is taking place outside of the user's typical access patterns, the system may determine that the login attempt is high-risk, and require additional factors of authentication, such as a one-time code sent to a mobile phone, or a biometric scan, to confirm the user's identity before allowing access.

By implementing adaptive authentication, the user experience is improved as they are not frequently asked for a second factor when it is not needed.

Assessing risk with Device Fingerprint

A system can know what device a user is using by using various methods such as browser fingerprints, device fingerprints, or device identification numbers.

A browser fingerprint is a collection of information about the browser and device being used, such as the browser version, installed fonts, and screen resolution, which can be used to identify a specific device.

A device fingerprint is a unique identifier that is created by combining various hardware and software characteristics of a device, such as the device's IP address, MAC address, and browser settings.

A device identification number, such as IMEI or serial number, can also be used to identify a device. IMEI stands for International Mobile Equipment Identity, it is a unique number assigned to every mobile phone.

Additionally, the system can also use cookies, local storage or browser storage to store the device information. Once the user returns to the website, the system can read the stored information to identify the device.

It's worth noting that these methods can be circumvented by the user if they use anonymity tools such as VPNs, Proxies, browser plugins or browser in private mode, so the system must also take into account other factors such as the location, behavior and IP address to determine the level of risk associated with a login attempt.

Assessing risk with IP Address

IP addresses can be used as a factor in determining the level of risk associated with a login attempt, but their relevance can vary depending on the context and the method used to obtain them.

In general, IP addresses can be useful in determining a user's location and identifying whether or not a login attempt is taking place from a known location. However, the accuracy of location information based on IP addresses can be limited, especially with the increasing use of VPNs, proxies, and other anonymity tools that can make it difficult to determine the true location of a device.

Also, IP addresses can be easily spoofed, which means that an attacker can use a different IP address to make it appear as if they are logging in from a different location.

Therefore, while IP addresses can be a useful factor in adaptive authentication, they should not be relied upon as the sole method of determining the level of risk associated with a login attempt. It is important to consider other factors, such as the device being used, the time of day, and the user's behavior, to make a more accurate risk assessment.