Exploring the Latest Trends and Technologies to Secure Your Digital Identity in the Modern Era

Intro

So, you have decided to develop an app for your organisation, and the app requires users to log in and interact with the app. How do you decide what authentication methods to use? In an age where data breaches make headlines daily, the security of your users’ identities isn’t just an afterthought — it’s a necessity. Imagine building a fortress but leaving the front gate unguarded. The same applies to your app’s security if you don’t choose the right authentication method. These days attackers aren’t breaking in, they’re logging in.

Let’s get the terms straight first! “Authentication” is a challenge to prove the user is who they say they are before the app allows them in. It is different from “Authorization” which comes in play once the user is logged in, when we decide what data, the user can access within the app.

In your quest to pick the right authentication, we are going to look at the aspects that drive method selection, the different methods, some good and bad examples, and finally, a typical method selection for an app developed in 2024 would look like.

Aspects that drive method selection

Data

What are you trying to protect? How sensitive is the data? A good indication would be if you have gone through and performed a data sensitivity classification of the data the app is dealing with. The popular ones are:

• Public: Data that is intended for the public.
• Internal: Data that is meant for internal use within an organization.
• Confidential: Sensitive data that should only be accessible to specific individuals within an organization.
• Restricted: The most sensitive data that could cause significant harm to the organization or individuals if disclosed.

The higher the sensitivity of data, the more secure the authentication method you should be inclining towards.

Users

Who are your app users: are they potential customers, customers, workforce, partners or citizens? Do they have access to the authentication methods you are planning to use? For example, citizen users may all not have access to hardware-based tokens. Understanding the users will help give you an understanding of what authentication methods they would be more comfortable using. You may not want to burden your potential customers with very strong authentication methods and risk losing them, and at the same time, you may not want very weak authentication methods for your users who are accessing confidential information, revealing that your app has weak security controls.

Costs

What are the costs involved in implementing and maintaining the authentication method? Some methods are easier to implement, like password-based authentication, while some methods are expensive to implement and maintain, like the hardware-based tokens, where they need to be purchased, and logistics need to be planned for distribution to onboard new users and in cases where users need token replacement. Another consideration is how easy or complicated it is to provide support to users for that authentication method from your helpdesk team.

Security

How secure is the method, and what is an acceptable level of user experience compromise you are willing to consider? An e-commerce website that requires digital certificates for authentication would probably see customers moving to a competitor because of the difficulty involved in setting them up. A banking website that solely relies on passwords for authentication or funds transfer would not be perceived as secure for customers either. So, you need to get the right amount of secure authentication for the right use case.

User Experience (UX)

The UX also needs to be factored in when selecting an authentication method; if the experience gets too annoying or difficult for the users, then that will directly impact app adoption. For example, if your app is primarily to be accessed on a mobile device and if it needs a hardware-based passkey for access, then not many mobile phones support that, and hence, it would be impossible for certain users to use the app. Another example would be if your app is primarily designed to be viewed on a desktop, and to log in, you need to click on a magic link sent on an SMS; the user journey would then continue via the mobile phone, which would be annoying.

What methods are out there

Let’s just list out all the methods out there that are available to be used and an indicative rating on their cost of ownership and security.

Factor 1: Something that you know

Factor 2: Something that you have

Factor 3: Something that you are

Context-Based (invisible) Authentication

Note: Context based authentication can form a great auxiliary authentication mechanism in addition to another auth method that you implement and should not be implemented on its own. This could further act as signals that feed into any risk engines in the company for reporting for further taking an action like blocking user authentication or suspending the account.

How to pick the right combination

Delving into each one of those is entirely a topic in of itself, which is outside the scope of this blog post. But in essence you have a quite a few options and selecting the right one would depend on the data, user and the capability of your organization to implement and maintain an authentication method. Each method comes with its own pros and cons.

Now, do you really need to pick just one? No, you can (and in fact should) mix and match the authentication methods based on the users and your applications. Authentication methods are often combined to provide a stronger authentication journey and an improved user experience. When you combine two authentication methods, remember to choose from different authentication factors. For example, combining two methods from the same category, “something you know”, like a password + PIN, does not increase the security posture. This is best done by combining methods from different categories or “factors”, which we then refer to in the industry as MFA (multi-factor authentication) or 2FA (two-factor authentication), such as a PIN or Password to open the home screen of the application and then a stronger form, like a TOTP, when the user accesses a more sensitive section or if their login profile is not normal.

Then how about picking all for ALL? Well, then, you’ll be totally messing up the user experience. We should only prompt for what we need and also what is appropriate — you can “step the user up” later, and you don’t want to go to the extreme. Let me show you some of the bad examples you may want to avoid:

1. If you are developing a web application whose users are don’t have a strong mobile uptake, choosing a Passkey authentication would probably be a bad idea as the user’s less likely to have passkey-enabled devices.
2. If you are developing an app that performs high value transactions for the organization, you would not want to rely on just a password authentication, as it’s the least secure one and extremely phishable!
3. If you are releasing a work footy tipping application where the top prize is $50 you are not going to force users to use password, answer a security question, do an eMail code for a new browser login and all go get a hardware FIDO key — it’s a little excessive for the value of the application.

Note: The modern MFA these days are leaning towards “Passwordless” these are basically taking advantage of stronger authentication solutions such as FIDO2 or Passkeys either software-based or hardware-based. Hardware-based are on the highest end of the security spectrum of authentication.

Wrap

Alright, so where does this leave us? As the tech landscape has advanced in 2024, so authentication method selection choices have advanced too. Here are some generic examples of authentication methods one would consider for the modern app landscape.

If you are developing an app whose users are predominantly a company’s workforce users (or Workforce Identity), then

Note: In a corporate setup, the general trend is that the company has issued laptops or computers to its workforce and the work apps are usually hosted on the company’s private. If they are to be accessed externally then they are allowed through an additional mechanism eg a zero trust network a VPN (virtual private network) that performs extra checks and encrypts comms between the user’s laptop and company’s network. When a company uses “passwords”, typically this is because their implementation of active directory or an application has passwords as mandatory and it may be extremely difficult to change this — password managers and other technologies like Kerberos can help here but that’s another blog.

If you are developing an app whose users are predominantly a company’s customer users (or Citizen Identity), then:

Note: If you plan to use a third-party social login like Google, remember that Google may have setup its own MFA. So, if you have setup your own MFA too, then the user’s authentication experience may get quirky, as they have to first use their Google account’s password, Google’s MFA which is most likely on a Google app on a mobile device and then your preferred MFA on the app. So, you end up losing your intended UX for the customer journey.

Finally, as you choose your authentication method(s), additionally consider the following:

• Any specific authentication requirements from relevant industry and government for the app context.
• How does the authentication method selection fit into the broader company business long term strategy, as if each app in the company uses a different multi factor authentication technology this would increase the TCO.
• Does the authentication method fit well into the enterprise architecture design and is it possible to get buy in from key stakeholders?
• Each authentication method has certain associated risks, and while the risks were not discussed in this blog, consider how well they fit into your risk appetite to meet audit requirements.
• Explore if it makes sense to use your local country’s government-based authentication solution instead of the popular social media logins like Google and FB for customer logins (such as MyGovID in Australia and RealMe in New Zealand).
• Consider implementing “Continuous authentication” and “Adaptive authentication”. Unlike traditional authentication, which evaluates users once at login, continuous authentication considers changing risk factors such as location, device posture, and other behavioural data over time. Adaptive authentication then comes into play by prompting the user for further authentication factors to continue the app’s session.