One of the main difficulties faced when deploying a multi-factor authentication solution (MFA) is to define the “optimal” form factor. For a given level of security, you would like the solution to be both convenient and universal – that is, to cover as many use cases as possible, for as many users as possible. This is a question we’ve thought about for a long time at inWebo because organizations are so diverse and constantly changing, and we’ve been challenged by our customers to propose future-proofed MFA strategies.

Smartphone-based MFA is great, but…

Let’s say for example that the service you’re trying to protect is a federation server managing authorization for both behind-the-firewall and SaaS applications. Depending on who the users are, where they work from, and with which devices they access the applications, you may want MFA to be totally seamless and “tokenless” by leveraging web browsers as authentication credentials keystores. This works best when users always access from the same set of desktops, tablets, or laptops because, although minimal, there’s an initial registration procedure for a browser to be used as a keystore, so it may become cumbersome when users keep changing devices, or impractical if devices are shared or public. Or you may want MFA to leverage smartphones, with contextual and out-of-band authentication requests pushed to the users so that they confirm access. This alleviates the need for registering browsers, hence enabling true mobility. However, this requires all users to be equipped with smartphones, which is a very strong assumption for employee-facing applications as well as for consumer-facing applications.

Non-optimal segmentations

So, in most real-world deployments, smartphone-based MFA (such as inWebo Authenticator or mAccess) is best for some users – or situations – and tokenless MFA (such as inWebo Helium) is best for the others. Also, that segmentation varies all the time. Indeed, if we’re speaking of employee-facing applications, you probably have the possibility to correlate with which devices you have equipped which users. How cumbersome! And if we’re speaking consumer-facing, you have no clue. Finally, what’s good for today’s applications is probably irrelevant for next year’s.

So no choice appears ideal or future-proofed, hence the dilemma mentioned in the introduction. Should you give up the idea of MFA, scale back to cumbersome and poorly secure SMS-OTP, or make a choice that will leave out users and load the hotline? Hopefully none of these!

Always-best-authenticated thanks to a platform approach

Discussing these situations with our early customers, we have designed flexible solutions where authentication connectors (APIs) provide an “always best authenticated” feature: the same user will be given the easiest option to authenticate, tokenless or out-of-band, in any given situation. Our authentication platform works the same way as payment options do for an e-commerce, e.g. accept checks, Paypal, debit and credit cards. If your payment gateway accepts them all, you’re sure not to leave any customer out, but also that customers can choose the method that they have with them or are the most comfortable with for any given transaction. However, you still define policies and may decide that checks aren’t allowed for carts above 500 dollars.

For example, Alice may therefore use her browser token (inWebo Helium) when she connects to her VPN from her tablet, and use her smartphone (inWebo Authenticator) when she connects to her Office 365 account to check her emails from the hotel business center’s desktop. And she can get the new smartphone she’s authorized to every 18 months as per the corporate policy, without ruining your MFA deployment. It’s seamless from Alice’s perspective. It’s also seamless for her company IT admin since he doesn’t need to keep track of the devices she’s equipped with, or to define a static, unique way of authenticating. Your IT admin now has an easier job: he defines authentication policies, which may differ from service to service, or from group of users to group of users. A policy basically lists acceptable authentication methods, that is, the authentication options a user will be proposed, as in the payment options example.

All this is possible because inWebo platform has been designed and built with a multi-device, user-centric approach that abstracts the credential (authentication methods) management.

Try inWebo solutions for free, and talk to us about your authentication challenges!