How to make strong customer authentication as tolerable as possible

I hate strong authentication. It used to be bad on desktop browsers, and then it got even worse on mobile. The situation has now improved a little, but it’s still nowhere near as easy as it should be.

As you might have noticed, authentication weighs heavy on my heart. Previously in the series, I’ve written about how authentication plays a role in three business-critical phases but is often neglected, how the best login is no login at all, and how to avoid using passwords. Now it’s high time to talk about strong customer authentication.

SCA is the acronym used in the payments context, if you want to research the topic. When it comes to authentication in other contexts, we are talking about eIDAS and the level substantial.

These are some the things that are going on right now:

• eIDAS + trust network (Luottamusverkosto):
  Authentication prices have gone down, integration has become easier for service providers.
• New digital authentication applications offered by banks:
  Authentication is more convenient than with the old paper code lists.
• The second coming of the mobile certificate:
  Application-based mobile certificates will be easier to adopt.
• PSD2 increases the need for streamlined strong authentication

On one hand, we’ve gotten used to the clumsy 3DS implementation over the years. On the other, if you do this well and provide your customers with a streamlined payment experience, this will give you the chance to stand out.

There is a good pattern and a bad pattern, the choice is yours

What can service providers do to make their customers’ lives easier? Not much, but still something:

• Minimize the need for strong authentication
• Ask for as much information as you can in one sitting

Terveystalo’s application is an example of a smart implementation. You go through strong authentication when you first use the app. After that, you can access your personal health data on the same device with fingerprint authentication.

Terveystalo only does strong authentication once.

You often come across different implementations as well. For example, Lähitapiola’s Elämänturva insurance app is pretty as a picture. But the moment you try to do anything, it throws you out of the app to go authenticate yourself again in the browser.

If you look at the app store ratings, you can see that I’m not the only one who doesn’t enjoy that. Nobody does things like that just out of spite though – there must be some kind of technical reasons for it, but the experience is bad.

Elämänturva cuts your path short.

You can also do a lot to spare users the trouble of authentication in connection with payment. This would really be an article unto its own, but you can get started by checking out Stripe. Or Adyen.

You can make the payment experience smoother by taking advantage of the exceptions in the PSD2 Directive. Image: Adyen.

Gleaning information in the background

Let me give an example of gleaning more information from users during strong authentication with the following fictive online store. The user wants to pay in installments and performs strong authentication. At the same time, the store runs a credit rating check and finds out the user’s address in the background. After this, the order is only one click away.

A sample online store implemented by Qvik and Signicat. It retrieves the user’s address information in connection with the authentication required for making a loan decision.

Various authentication service providers will probably start offering ever more diverse add-on services to service providers: the business value of authentication alone will fade with tightening regulation and competition. You could imagine this will be an improvement for the user too, since more offering tends to mean a better user experience.

What would convenient strong authentication look like?

The implementations of banks vary. The following image presents the different stages of the process and the requirements for success in each one.

Every step on the authentication path can be made easier or harder.

First, the user needs to tell the online service who they are, one way or another. You could do this like the banking apps, with a secret user ID that you have to memorize. In the trickiest implementation, you will also need a separate password. The mobile certificate uses your phone number, which is easy to remember, but also known to others, who can then send you authentication requests for phishing purposes. That is why there is an optional security code but it is a difficult concept for the very people who would benefit from it.

The next phase will be switching over to the authentication app. If you are operating solely on mobile, it would be best to redirect the user automatically to the right application. And if the user will authenticate themselves on a computer, it would be nice to send an authentication request notification to their phone, so that they will not have to dig up and open the authentication app themselves.

All this is followed by the actual authentication phase. Many questions arise.

• Can you use biometric authentication, or will you need to enter a PIN?
• How many more needless screens will you need to sit through?
• Can the service link you back to the original application, or will you have to do the app switch manually?

Case Nordea – bank authentication done well

Nordea offers a pretty streamlined solution to strong authentication. There’s really only one superfluous step that makes you wonder before you hop into the authentication app. And you can’t get your browser to remember your user ID even if you’d like to. This is when the automatic app-switch to the authentication app works. In some situations you still need to do it manually.

Nordea also lets you use biometric authentication inside the app – if you manage to find where to enable it. The positive application store feedback is a good indicator that the process is rather painless. If you take a look at other banks’ code apps and count the steps in the authentication process, you can see that the more steps included, the worse the application ratings tend to be.

Nordea has also been rolling out the new mobile-optimised payment flow since summer 2020. I have not encountered the old desktop site anywhere in a while now. One place where you can easily try it out is the Finnish Red Cross. If you ever wanted a good reason to donate money, here you have it!

The new payment flow is nicely mobile-optimised but for some reason it still asks you to authenticate twice. First you authenticate to get into your account and then again to confirm the payment, with several manual app-switches required. What is more, you can’t use biometrics when confirming the payment but need to key in your PIN code instead. I still find it confusing and complicated.

The mobile certificate is getting more popular

Traditional mobile certificates are doing quite well in the race against the banks.
The authentication method provided by telcos is based on an application hiding on your SIM card, and every phone manufacturer shows the required dialogs in its own way. The upside of this is that the technology lets the transactions open right in context, so you won’t need to switch between apps.

But the fourth step in the implementation, asking you which information to pass on to the service providers, sticks out like a sore thumb. If Nordea doesn’t need that either, I don’t think it merits an entire step in the process.

The first-generation mobile certificate does quite well in comparison to the solutions offered by banks.

According to Ficom’s statistics, the mobile certificate doubled its user base during 2019, with over 7 million authentications done with the certificate. Precise user counts have not been published, but I have heard estimates that there are hundreds of thousands of users – possibly even half a million.

Mobile certificate usage doubled last year.

In many services, the mobile certificate is the third-most popular authentication method after the largest banks. The principal reason for this is thought to be the method’s broad support. The authentication method is accepted by practically everyone except the banks.

That’s actually pretty much what the forecasts for the mobile certificate’ success are based on. The pricing model for the upcoming second generation has not been disclosed by telcos. If you will still have to pay for strong authentication like in the current version, without even getting rid of your bank’s authentication solution, how many consumers will want to pay just for logging into other services more conveniently? Hard to tell at this point.

Telcos have publicly stated that the app-based 2nd generation of mobile certificate would be launched in 2020 but since there has not been any news recently, I would not be surprised if it was postponed to 2021.

Go, West!

This is a good time to cast our eye to the west and ask the age-old question: ”What about Sweden?” Well, Sweden uses the banks’ shared mobile wallet Swish and joint authentication solution BankID.

This is how convenient it is to make a payment and authenticate yourself with this combination: You just show your face to Face ID in between and linking between apps is handled automatically.

That’s how they do it next door.

In Norway, Vipss does pretty much the same thing. You can use it for authentication as well as payment. It also transmits your name, email, phone number and delivery address to the merchant, avoiding the need to register with every single one.

Illustration: Aija Malmioja