Connecting users to apps and websites is paramount for any business. From a security and business perspective, you want to know the identity of your users. Yet login distracts from your core functionality – before the user can start interacting with your business, they must go through authentication. Thus, companies try to make the authentication user experience as seamless as possible.
However, creating great sign-in experiences can take time and effort at the expense of other priorities. And increased security often makes the login process more cumbersome and creates problems for users logging in or creating accounts.
For example, maybe your company requires the user to have a special character in their password that they forget, requiring them to reset the password each time they try to log in. your customer process, which may be too complex for some less technically savvy users. The last thing your business wants is to lose customers because you provide a more secure solution.
Authentication is a journey
Much of the complexity of authentication stems from the fact that authentication is no longer a simple act of providing a username and password. It is a journey the user takes to confirm their identity and gain secure access to their resources. Users can choose between different authentication methods, some of which may require them to verify their identity with second factors.
Authorization servers can make authentication decisions based on many variables. They may reject after-hours authentication or require more stringent authentication methods if the user appears to have traveled a long distance in a surprisingly short time. External services may be contacted to assert user information. The list continues.
The navigator is the ship
To complete this complicated authentication journey, the user needs an appropriate vessel, and so far we have used browsers for this purpose. The browser is a solid choice because it gives us essential security features. For example, browser-based authentication helps keep passwords out of apps. In OAuth and Open ID login (OIDC), an HTTP redirect made via the browser proves the origin of a client.
However, when considering the mobile world, the browser can become a liability. When used in a mobile application, the user is often switched to another application to authenticate. The application sends the user to an external browser or implements complex custom tabs or web authentication session. Such a solution usually means that your users are not getting the best possible experience.
Also, a significant part of your business relies on the whim of browser vendors, and they can suddenly change APIs or remove features. This not only affects your users, but makes the development process more difficult.
Hypermedia is the engine of flows
If the navigator is a vessel, then hypermedia is the landscape through which we travel. We are so used to the Web being driven by hypermedia that we usually forget this fact. Basically, hypermedia is a collection of pages (texts) connected to each other with links that allow us to traverse between them, and once we remember this we can come to a simple conclusion — the browser manages the rich user authentication because it’s a hypermedia stream.
Hypermedia allows users to step through authentication steps as needed, which may be unique for each connection. Thus, a hypermedia API can be used to perform complex authentication flows on mobile devices without resorting to the browser. This allows the user to go through a complex authentication flow without switching apps. It will remain in the context of your application throughout the journey.
More control, more security
Keeping the user in the context of your application isn’t the only benefit of a Hypermedia Authentication API. Another advantage is the use of native components for authentication screens. This simplifies development because your teams only need to work on the theme in native application code – they don’t have to separately create bespoke views to display in the browser-driven parts of the flow. Not to mention, it’s easier to style native UI components than to write complex CSS rules.
Using a hypermedia authentication API, the authorization server now communicates directly with your application, opening up the possibility of another security upgrade. The authorization server can attest to the client application before authorizing the start of authentication, which means that it can attest:
- That it is talking to the legitimate app registered in the Google Play Store/App Store.
- Whether the app is running on a device that is not rooted or jailbroken.
The attestation will allow the authorization server to prove the client’s provenance even if no browser redirects are in place. Achieving this level of security is not possible when communicating with the authorization server via a browser. (If you want to learn more about how attestation works, see this hypermedia authentication white paper published by Curity.)
Browser removal of authentication may raise some eyebrows – after all, it means user passwords are now entered directly into the app.
It’s okay if the app is owned by the same party that owns the user data (a proprietary app). The party knows these passwords anyway, and it is not a security issue that they are not entered through a browser. However, if a third party is used to authenticate users (such as authenticating users with their Google accounts), a browser would still be required to populate at least some parts of the feed.
Strengthen security with hardware
Performing attestation is possible thanks to the APIs exposed by Android and iOS. These APIs are supported by hardware modules responsible for the secure storage of cryptographic keys. This makes attestation a reliable security mechanism, as hardware-based security solutions are much harder to break.
Recently, another solution has emerged that could be backed by hardware to ensure the best protection of the authentication process. Web Authentication (WebAuthn) allows users to authenticate to applications and websites using secure cryptographic keys. Not only are these keys securely stored on the user’s device, but access to them can be protected with biometric features.
The WebAuthn standard will make the Internet more secure by encouraging passwordless logins. Hackers won’t be able to steal and reuse people’s passwords if there are no passwords.
Solutions without a password, like WebAuthn, make your applications resistant to phishing attempts. The cryptographic keys used to authenticate the user are tightly coupled to your domain. They are never published on any other website, regardless of the resemblance to its name. For example, if you operate your business on example.com, your users’ credentials will never be used on a malicious example.com. (See what “I” is there? This is exactly what is behind phishing attacks. In one of the addresses, the “L” is actually a capital “I”. Attackers use the ability to register domains that use characters that look like legitimate ones.)
Once no password becomes standard as a first authentication factor (currently it is generally used as a second factor), this will improve the user experience as well. The user won’t have to remember many passwords, use password managers, or risk reusing passwords on different websites.
Web authentication is not limited to mobile devices. Most browsers already support it, at least partially (for some it requires an external hardware security keychain, like Yubikey), so going passwordless is also possible on the desktop.
It’s high time to step up security
Now that mobile devices and apps are dominating the world, it’s time to upgrade the authentication flow security and user experience. One strategy is to eliminate the browser and move to a hypermedia authentication API that allows complex authentication in native code. Another method is to phase out passwords and move to hardware-based identity solutions like web authentication. Together, these features will help make your apps and websites a more secure environment for your users.