Say Goodbye to Browsers and Passwords
Logging users into apps and websites is paramount for any enterprise. From a security and business perspective, you want to know the identity of your users. Yet logging in 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, building great login experiences can take time and effort away from 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 business requires the user to have a special character in their password that they forget, which makes them resort to resetting the password every time they try to log in. Or perhaps you require the user to go through a convoluted know-your-customer process, which can prove 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’s a journey that the user takes to confirm their identity and gain secure access to their resources. Users can choose between various authentication methods, some of which might require them to verify identity with second factors.
Authorization servers can make authentication decisions based on numerous variables. They can reject an authentication outside of business hours, or require stronger authentication methods if the user seems to have traveled a long distance in a suspiciously short time. External services might be contacted to assert information about the user. The list goes on.
Authentication is a journey.
The Browser Is the Vessel
To complete that complicated authentication journey, the user needs an appropriate vessel, and so far, we have used browsers for that purpose. The browser is a solid choice as it gives us essential security features. For example, authenticating through a browser helps keep passwords out of applications. In OAuth and OpenID Connect (OIDC) flows, an HTTP redirect made through the browser proves the provenance of a client.
However, when the mobile world is considered, the browser can become something of a liability. When used in a mobile app, the user is often switched to another application to authenticate. The app sends the user to an external browser or implements a complex Custom Tabs or Web Authentication Session. Such a solution usually means your users do not get the best possible experience.
Also, an important 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 harder.
Hypermedia Is What Drives the Flows
If the browser is a vessel, then hypermedia is the landscape through which we travel. We’re so used to the web being driven by hypermedia that we usually overlook that fact. Basically, hypermedia is a set of pages (texts) connected to each other with links that allow us to traverse between them, and once we remember it, we can come to a simple conclusion — the browser handles rich user authentication because it’s a hypermedia flow.
Hypermedia allows users to traverse authentication steps as needed, which might be unique for each login. 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 follow a complex authentication flow without switching apps — they will stay in the context of your app through the whole journey.
Flow with a browser vs. a hypermedia API
More Control, More Security
Keeping the user in the context of your app is not the only advantage of a hypermedia authentication API. Another benefit is using native components for authentication screens. This simplifies development as your teams only need to work on the theme in native app code — they don’t have to separately create bespoke views to be displayed in the browser-operated parts of the flow. Not to mention that it’s simpler to style native UI components as compared to writing complex CSS rules.
The styling in a browser might eventually break when vendors update their products or when an obscure browser app is used. Sticking to native code is also a strong protection against cross-site scripting attacks, as no JavaScript code is used in the process.
Using a hypermedia authentication API, the authorization server now talks directly to your app, which opens up the possibility for another security upgrade. The authorization server can perform an attestation of the client application before allowing authentication to begin, which means it can attest:
- That it is talking to the legitimate app registered in the Google Play Store/App Store.
- That the app runs on a device that is not rooted or jailbroken.
Attestation will allow the authorization server to prove the provenance of the client even though no browser redirect is in place. Achieving that level of security is not possible when communicating with the authorization server through a browser. (If you want to read about how attestation works in detail, have a look at this whitepaper on hypermedia authentication published by Curity.)
Removing the browser from the authentication might raise some eyebrows — after all, this means user passwords are now entered directly into the app.
This is not an issue if the application is owned by the same party that owns the user data (a first-party app). The party knows these passwords anyway, and it’s not a security issue that they’re not entered through a browser. However, if a third party is used to authenticate users (like authenticating users with their Google accounts), then a browser would still be necessary to fulfill at least some parts of the flow.
Strengthening Security with Hardware
Performing attestation is possible thanks to APIs exposed by Android and iOS. These APIs are supported by hardware modules responsible for the safe storage of cryptographic keys. This makes attestation a reliable security mechanism, as it’s much harder to break security solutions backed by hardware.
Recently, another solution emerged that could be hardware-backed to ensure the best protection of the authentication process. The Web Authentication (WebAuthn) standard allows users to authenticate to apps and websites using secure cryptographic keys. Not only are those keys securely stored on the user’s device, but access to them can be guarded by biometric features.
The WebAuthn standard will make the internet safer by encouraging passwordless logins. Hackers won’t be able to steal and reuse peoples’ passwords if there are no passwords.
Passwordless solutions, like WebAuthn, make your applications resistant to phishing attempts. The cryptographic keys used to authenticate the user are strongly coupled to your domain. They are never released to another website, no matter how similar it’s named. For example, if you operate your business on example.com, your users’ credentials will never be used on a malicious exаmpIe.com. (See what “I” did there? That’s exactly the thing 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 similar to the legitimate ones.)
Once passwordless becomes a standard as the first factor for authentication (currently it’s usually used as a second factor), it will also improve the user experience. The user will not have to remember numerous passwords, use password managers or risk reusing passwords among 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 key fob, like Yubikey), so turning to passwordless is also possible on the desktop.
It’s High Time to Step up Security
Now that mobile devices and apps dominate the world, it’s time to upgrade the security and user experience of the authentication flow. One strategy is to eliminate the browser and switch to a hypermedia authentication API that allows complex authentication in native code. Another method is to gradually phase out passwords and switch to hardware-backed identity solutions like Web Authentication. Together, these features will help make your apps and websites a more secure environment for your users.
If you want to learn more about how we’ve approached the hypermedia authentication API at Curity, then have a look at this demo Android app or demo iOS app.
