Have you ever tried to log in to your bank account or some other online application and, after you submitted your username and password, you were told to enter a code that you should receive within a few minutes via email or SMS? So now you have to just sit and wait for that code to come in and now you are a bit annoyed because you have to wait several minutes to do something very simple that should have taken less than a minute. Or perhaps you go do something else while you are waiting. Fifteen minutes or so later, when you go back to check to see if you got the code, you grab it and enter it in, only to find out that it expired five minutes ago. Now you have to request a new code and wait again. Experiences like this can be exhausting to end users.
Why do developers force users to go through all of this just to log in? Well, the answer is simple - security! Time and again we have seen that systems that rely only upon usernames and passwords for authentication are vulnerable to cyber attacks. The question is - Do we have to compromise on user experience in order to ensure that users are logging in securely? The answer is - NO.
There are much simpler ways of getting users to provide additional authentication factors. Three main options that are easy for users to use are:
Authenticator Apps typically run on mobile devices, though, some can run on desktop OS’s as well. These apps are usually built using the same standards so you can use authenticator apps like OneLogin Protect or Google Authenticator to provide authentication to multiple applications. These apps basically provide the same types of codes that the email or SMS messages deliver. But they generate the codes themselves, thus users are able to provide the codes much faster than they are when they have to wait for an email or SMS to arrive.
Authenticator apps like OneLogin that support push notifications make the user’s job much easier. They get the push notifications, log in to their phone and click a big button that says something like “Accept.” The only thing a user needs to be able to do to take advantage of this convenient form of authentication is to have a device that supports an authenticator app and register the app with the application or website. The registration process is usually just a matter of having to scan a QR code on the monitor.
Some applications have even gone the way of passwordless authentication. In fact, OneLogin has this option if you have Smart Flows enabled through SmartFactor AuthenticationTM. With passwordless authentication, a user would simply need to authenticate using their authenticator app and wouldn’t be prompted for a password at all.
Webauthn allows websites to take advantage of FIDO2 specifications. Among other things, this means that users can log in to websites using biometric authentication methods like fingerprints or facial recognition that are built into their devices. For example, if WebAuthn is an authentication factor that has been enabled for my OneLogin account, I as a user, can add it as one of my authentication factor options. All I really have to do is click a button to enable it. Then when I need to provide an additional authentication factor to get into my OneLogin Portal, I just need to scan my fingerprint from my laptop or use the facial recognition on my phone. This method is very simple and quick. The only drawback is that they need a device that supports FIDO2 authentication methods.
WebAuthn could also be used as a strong authentication factor in a passwordless authentication flow.
Adaptive Authentication keeps track of user’s login behavior: where they are logging in from, the time of day, the device they are using, etc. This works well for certain types of applications, ones that users use on a regular basis: paying bills once a month, watching movies every night, etc. The idea behind adaptive authentication options like OneLogin’s SmartFactor Authentication provides is that the user’s behavior becomes one of the authentication factors. Thus, when a user’s login attempt matches their typical login behavior the system can be set to not prompt them for any additional authentication factors beyond their password. This makes their login process that much easier. Or if the login attempt is drastically different from their normal behavior the login attempt can be denied. This can ensure an extra level of security. Even though it is difficult to mimic a user’s behavior, it is not recommended to rely upon their behavior as the only authentication factor, so you would not use this as your single authentication factor in a passwordless authentication flow.
When designing an application or a website, end-user experience has to be considered a high priority. If the experience is tedious or difficult, end users will “walk away.” They will leave the site, won’t use your application, and that can certainly hurt your business. Even for sites that they have to use like their bank site or the DMV, the user’s login experience needs to be simple. If they can’t easily log in they are going to call in or go directly to the location to talk to someone. These types of interactions cost time and money. The websites are often there to offload the need to have humans on call to help customers. Thus the websites should be saving the organization money. But if the websites aren’t easy to use or users can’t easily log in to them, then they aren’t going to be used and they won’t save any money. A simple and secure user login experience will save both time and money.