Welcome to the second part of our blog series on the state of passwordless authentication. In the first blog, we focused on the new kid on the block, passkeys, and how this emerging technology will likely have a significant impact to the advancement of the identity and access management industry’s desire to finally eliminate passwords for good.
In this blog, we are going to look at alternative options which can be used if passkeys are never going to be an option for your organization or if you need to implement a passwordless solution for the short/medium term. This maybe be the case if you’re waiting on the passkey technology to mature a little more, or if you’re going through various digital transformation projects within your organization which will then open the door to modern technologies such as passkeys.
Getting a better understanding of passwordless
When we talk about passwordless solutions, we are essentially talking about using authentication factors which were traditionally associated with providing a multi-factor authentication (MFA) solution. That is, of course, usually supplementing the username and password authentication factor with additional authentication challenges such as a time-based one-time password (TOTP), a mobile app push notification, a physical security key, etc.
OneLogin supports a wide range of authentication factors that can be used for MFA use cases. These factors can be used in a traditional flow (e.g., after a username and password combination) or in a brute force protection flow (e.g., first an MFA factor followed by username and password combination). The good news is that the OneLogin platform also allows you to use any of the available MFA authentication factors for your organization’s passwordless solution.
Defining user security policies in a passwordless solution
Controlling your end user’s authentication experience with OneLogin is simply a case of defining a user’s security policy which is configured to meet your requirements and then allocating this policy to your users. There is always a one-to-one relationship between a user and a statically assigned user security policy. This makes it very easy to identify not only the current experience each user will be presented with, but also to change that experience by just assigning them an alternative policy.
The allocation of a user security policy to a user can be fully automated using the OneLogin mappings capability. Mappings will typically be used to allocate a OneLogin group to a user (based on rules defined in the mappings rule base) and this group will have a user security policy attached to it. You can configure this in the Admin Console, or you can also apply your mapping rules programmatically (pro tip – Try the OneLogin Terraform provider!) via the OneLogin mappings API.
One of the most significant configuration items in the user security policy is the sign-in flow, which offers three modes of operation. One of those modes is the passwordless sign-in flow. When this is enabled on a policy it simply means the end user will never again see the dreaded “Username and Password” dialog box we all love to hate. One little tick of a box and no password prompts ever again! Absolute bliss!
So, before we go rushing off to tick this box we need to think about a couple of things. The first thing we need to decide is what are we replacing the dreaded password with? As mentioned above, we have a wide range of authentication factors available on the OneLogin platform that can be selected to meet your specific needs. We will dive into some of these available options a little later in this blog. The next thing to consider is how and when we will allocate these new user security policies providing the bliss to your users. The main pre-requisite here is making sure that all your users have already registered the required authentication factors you want to use in your solution as you cannot allow registration of the required authentication factor within a passwordless user policy just requiring that factor itself because… well, that just wouldn’t be too secure now, would it?
You can also fully pre-register certain authentication factors on behalf of your users if you have trusted information you know to be correct such as a verified email address or verified mobile phone number if you want to use the email or SMS authentication factors in your passwordless solution. By pre-registering these authentication factors on behalf of the user, this means they will have an authentication factor configured against their account (and without any end-user involvement) which is all ready to go and the door to start using those blissful user security policies is opened wide. Alternatively, you need to allocate user security policies with the traditional, username and password followed by MFA, sign in flow to your users for a period of time to allow secure registration of the relevant authentication factors you would like to use in your passwordless solution.
Migrating to passwordless for increased protection and a better user experience
Now, you have reached the stage where you know which authentication factors you want to use in your passwordless solution, and all your users have registered such factors to their accounts, but how can you migrate to the new passwordless user experience to make the bliss a reality? Well, there are two options which you can take depending on your appetite for automation.
The first option is the “Admin-driven” approach whereby your OneLogin Admin team will need to initiate the process of switching user security policies assigned to users when it is fully confirmed that they have the required authentication factors registered against their account. This process can be semi-automated using the mappings capability mentioned earlier in this blog, but ultimately a OneLogin Administrator needs to trigger the re-assignment of the statically assigned user security policy when it is validated that a particular user is “ready to go” for the move to passwordless life.
The second option is to allow the OneLogin extensibility capability known as Smart Hooks to do the challenging work for you. With this approach, you can use the Pre-Authentication Smart Hook capability to dynamically apply an alternate user security policy to a user based on elements of the “context” of the incoming authentication request to the OneLogin Platform. The key to this approach is leveraging the “MFA Devices” context which is made available to the Smart Hooks service each time an authentication request starts. This context will provide a list of registered authentication factors for the specific user starting the authentication flow to the Smart Hooks service so that this information can be evaluated in the conditional logic you can include in your Pre-Authentication Smart Hook Java script function.
So, you can use this approach as your own customized “passwordless policy allocation engine” whereby your conditional logic will determine which passwordless policy is allocated to a particular user based on a wide variety of factors. You can also keep this logic extremely simple for simple requirements or as complex as you need and even store the whole Smart Hook configuration as code in your version control system and deploy it using DevOps approaches each time you need to make a change to the logic, if that is your preferred mode of operation. We have recently released a new public GitHub repository containing various automation solutions and within it you can find samples of Smart Hook configurations which you can use as starting points for your own implementation. You can learn more about the OneLogin Pre-Authentication Smart Hook here.
Watch this video to see how the OneLogin Smart Hooks capability can control the passwordless authentication user experience based on authentication factors registered to a user.
Taking an advanced authentication approach: Combining passwordless and adaptive authentication
Now that you have fully implemented the migration to your passwordless solution for all your users, what else can you do to improve your security posture against those persistent threat actors that may still try to attack your users even when the weakest link of the password has been removed from the equation? Well, you can supplement your solution with other security controls from the OneLogin Platform of course!
There are two main additional controls you can layer on top of your passwordless solution to move towards advanced authentication. These controls may be used independently or together – it depends on what works best for the needs of your organization. The first additional control you can apply is layering OneLogin’s adaptive authentication solution, SmartFactor Authentication. It uses machine learning to analyze a broad range of inputs, such as location, device, and user behavior, to calculate a risk score and determine the most appropriate authentication flow and security action to take for each login attempt. Depending on the detected level of risk, SmartFactor Authentication adjusts the authentication factors needed to log in. For example, it can dynamically switch the user (Smart Hooks is the master here!) into a different passwordless-based user security policy (which may require a less convenient/higher friction authentication factor) based on a calculated elevated risk level.
The second additional control you can layer on top of your passwordless solution is the OneLogin App Security policy capability. By using this capability with your passwordless solution, you can mandate that an additional passwordless authentication factor (different from the one required by the user security policy level) is required to access either specific applications integrated into your OneLogin environment or all applications. By using this approach, you can “chain together” two completely separate authentication factors into your combined passwordless solution where security requirements may be significantly high. You can also join the adaptive authentication and OneLogin App Security policy approaches together to only block access to specific high value applications if the risk level exceeds your risk threshold.
Pros and cons of native OneLogin passwordless authentication factors
We will now look at the pros and cons of some of the authentication factors available when using OneLogin and adopting passwordless.
OneLogin Protect
Details: OneLogin Protect is our free mobile solution that allows users to submit their one-time password (OTP) by pressing a button. Available on iPhone and Android.
Pros: Convenient tap and approve mobile app experience for users. Can enforce additional controls around mobile device security posture (e.g., require screen lock and/or biometrics, block jailbroken devices).
Cons: Access to mobile phone is required. Organization policy may require corporate managed mobile is provided to all staff. Organization may face resistance from users to install a “work app” on personal phone. It can be bypassed by advanced attacks such as man-in-the-middle (MITM) attacks or become the target of push notification storm attacks.
Summary: OneLogin Protect is a great candidate for a passwordless authentication factor for your workforce solution where your users have access to a smartphone at all times. You may wish to layer additional authentication factors on top of it, using the OneLogin App Policy capability for particularly sensitive environments or specific applications. It is not a good fit for CIAM solutions as customers are unlikely to want to install yet another mobile application on their phone.
OneLogin SMS
Details: A one-time password (OTP) is sent to the mobile phone number associated with a user over SMS.
Pros: It is a convenient solution for users that can access a mobile phone with cell network connectivity at all times.
Cons: Requires copying or typing a 6-digit code (Note: It can be less inconvenient if the user is using their mobile device anyway to access a service.) Can be bypassed by advanced threat actors like SIM swapping, carries a cost per authentication, requires an SMS Gateway provider.
Summary: OneLogin SMS is a good authentication factor for CIAM passwordless use cases, but does mean additional cost for the CIAM solution. For workforce identity, this authentication factor could be a good fit for limited use cases until a stronger authentication factor is available for the user. For example, a new user signs in for the first time via SMS. Then, the user is forced to register a stronger authentication factor which would be used for all subsequent authentication requests.
OneLogin Email
Details: OneLogin sends an automated email to the user’s email address to authenticate the user.
Pros: Convenient solution for users that can access a non-corporate email account at all times. The Magic Link option provides a better user experience compared to the OTP copy/type process.
Cons: Assumes the registered email account of the user has not been compromised which may not be the case.
Summary: This is a good authentication factor for CIAM passwordless use cases where security requirements are not particularly high, especially with the Magic Link approach. Similar to OneLogin SMS, this authentication factor could be a good fit for very limited use cases until a stronger authentication factor is available for the user.
Additional passwordless authentication factors
OneLogin also offers several authentication factors leveraging external partner solutions which can be used in your passwordless solution. These include factors like legacy YubiKeys, Google & Microsoft Authenticator Apps, Duo Security and the ability for OneLogin to act as a Radius client to an External Radius server solution. While some of these solutions may fit niche use cases in your passwordless solution, we recommend that any organization in the process of designing a new passwordless strategy should prioritize the native OneLogin provided authentication factors mentioned above (along with Passkeys as mentioned in our first blog of course!).
Organizations should also factor into passwordless design considerations the newest authentication factor made available on the OneLogin platform – the BYOD MFA/Trusted IDP as a factor capability.
