Single sign-on (SSO) and identity-as-a-service (IDaaS) platforms are rapidly becoming standard tools across the business world—and with good reason. As companies use a wider and wider variety of cloud-based software applications, employees face more and more login prompts over the course of their everyday work.
And these logins are increasing if each of five logins in a multi-step workflow takes a user 1-2 minutes to complete thanks to the growing proliferation of multi-factor authentication (MFA), a 60-second workflow can instead become a confusing 5-10 minute ordeal marked by repeated, distracting interruptions.
This is a productivity-killer, particularly when employees are encouraged to use longer and longer passwords and when more and more login prompts are protected by SMS or one-time-password (OTP) multi-factor authentication (MFA).
SSO Solves Some Problems, Creates Others
SSO strategies make it possible for users to just get on with work by bypassing logins and MFA steps. That's good for productivity.
And on the surface, everything remains secure—SSO environments rely on the exchange of tokens proving that the user did recently authenticate successfully. The implicit SSO claim is "we've already confirmed who this user is, so let's not prompt them for another login."
The problem, of course, is that this claim isn't justified. What SSO platforms actually know is who an open session was initiated by, not who is sitting at the keyboard right now.
In the most benign case, a legitimate user can log in at 8:00 am and then hand their device to someone else to do work for them for the rest of the day—without worrying about obstruction from further login prompts.
More worrying cases include devices that are stolen while still logged in, or users that walk away from their devices without first logging out, after which strangers or unauthorized users step in. In these cases, a stranger can immediately log into any number of other protected systems without credentials or resistance, thanks to SSO.
This shows that SSO is really about convenience—not security. Logins are there to control access to secure systems. SSO bypasses these checks for convenience, in a way that's deemed to be a tolerable compromise for increased productivity.
Balancing Risk vs. Convenience
What administrators are faced with is essentially a knob that they can turn to control the risk vs. convenience tradeoff by controlling the length of SSO token life:
-
At one and of the scale is total security—no SSO token. But at this end of the scale they’re also faced with the maximum negative productivity impact—users have to log in every single time to every single system.
-
At the other end of the scale is total convenience—SSO tokens that last or refresh forever. But at this end of the scale there’s essentially no security—every system can be accessed without a login prompt at any time following an initial login in the past.
In practice, administrators typically turn this knob to somewhere in the range of hours to days, accepting that throughout the period that they surrender to SSO logins, the identity of the user is presumed each time there's a login prompt in the name of speeding things up, even if this is a risky assumption.
Eliminating the Tradeoff
The better solution to all of these problems is to find a way to confirm the user's identity at the time each login prompt is presented—without forcing them to enter a username, password, or OTP MFA code.
This sounds impossible at first glance, but it's actually simple to accomplish with technology already on the market today. Here are the steps:
-
Deploy a continuous authentication solution that confirms identities in real time as users work.
-
If this real-time identity confirmation fails (indicating that a different user is now using the device), revoke the SSO token or session, ensuring that no further logins can occur without reauthentication—username, password, and OTP MFA.
This setup neatly eliminates the need for a knob—users can be saved the trouble of having to cope with endless password prompts but the login prompts will reappear if and when a change in the user has been detected.
Making the Solution Practical
The only snag about the strategy outlined above is, of course, that you need a tool or technology that can provide real-time identity confirmation—the signal that you use to decide when to revoke the SSO token or session.
Happily, in today's cybersecurity world, this technology exists. Plurilock's™ implementation uses behavioral biometrics to confirm identity continuously as the user works—and to make this confirmation available to SIEM and other systems for analysis and action.
As a result, users of Plurilock DEFEND™, for example, can implement precisely this strategy—deploying SSO sensibly with the trust that logins are bypassed only if the same user that originally authenticated is at the keyboard—and not someone else.
Today we have the tools in place to enable the convenience of SSO without its biggest security liability—so it's time to make the pairing of SSO with continuous authentication tools a taken-for-granted best practice. ■
