Passwords are extremely common throughout the web. Unfortunately, though, passwords also bring many problems with them. And more than anything else, they centralize authority for how a user experiences authentication under a server. This results in a simple system that carries a wide range of faults.

Enter hypermedia. Hypermedia as a solution promises to enable passwordless and return the determination of the experience back to the client. How does it do this? And more importantly, what does it enable for users?

For answers, we can look to one excellent talk by Travis Spencer, CEO of Curity. This post is a companion to his presentation “Using Hypermedia to Adapt Client-side Login to Go Beyond Passwords“, presented at the 2021 European Identity and Cloud Conference.

Why Are Passwords Still Common?

Passwords are still ubiquitous for one reason — they are extremely easy to implement for the client, the server, and the user. Username and password flows are about as simple as you can get when it comes to authentication, even with added complexity when adopting multi-factor authentication solutions.

Ultimately, passwords are a simple check from the server that you know something, accomplished by collecting two data fields. On the client-side, this pair is easy to transmit. On the user side, you only have to remember two things, which are often recalled through memetic devices or memory techniques.

Ultimately, the end-user has decades of training for how to use a username and password, and for that reason, it has become the de facto method for almost all modern applications. A simple pair to remember, a simple post — what could be the problem with that system?

Why Move Away from Passwords?

Unfortunately, passwords have major drawbacks that make them somewhat dangerous in isolation. Username and password pairs depend on the client and the server being trusted at all times. They also hinge on the user securing this information. But what if the user accidentally leaks their password? What if their password is 123abc? The weakness of the password flow makes it so that access can be breached in many ways.

This isn’t always the fault of the user. Dictionary attacks and rainbow tables are commonplace, and directed attacks often utilize personal connections. For instance, your favorite dog Charlie and birth year of 1968 could form the password Charlie68. Let us not forget that data breaches occur frequently, and users often use the same password for each service. In such a case, a single lost password could result in massive exposure across many services.

Simple But Effective: Hypermedia as a Path Forward

Given these weaknesses, a new solution is required. This solution must be simple for the user and the client. However, server complexity is acceptable if it brings enough additional security and added value.

Hypermedia meets these requirements well, and enables a significant amount of potential. Before we dive into how hypermedia enables passwordless interaction, we should note that hypermedia is nothing new — it’s the architectural approach that drives the worldwide web, forming the value proposition of the internet. Whenever you use Twitter or read an article on Nordic APIs, you view content linked together in a rich web of interconnected media. This connection and linking from resource to resource is the crux of hypermedia, and it is this connection that we can leverage to deliver a passwordless experience.

In a hypermedia-driven solution, the server dictates what credential types should be used by utilizing reference links and redirect commands to guide the client through a state machine. This state machine is essentially the guiding resource for the authentication pattern. It helps the client and user set their login state and interaction stance according to the server’s pattern and flow.

The best part of all of this is that the user experience is the same, if not improved. In the worst-case scenario, the user still gives the same data to the client, and the rest of the process is handled seamlessly. However, if the user needs a different flow, hypermedia truly shines, allowing the server to provide that flow, guiding the user towards the same end state effectively.

Leveraging OAuth and OpenID Connect

We can further simplify this process by building our hypermedia solution upon standards like OAuth and OpenID Connect. Utilizing these standards, we can create a client-server process that is simple, transparent, and efficient, providing both a default flow and a collection of unique flows for specific circumstances. The client process for login and entering the state machine can follow a standard path. In this path, we will allow the client to submit a request, pushing their request into a negotiation. The prime difference between a standard flow and this new flow, however, is that the negotiation is now amongst a set of different state representations.

Because hypermedia leverages a wide variety of standards, the client doesn’t just receive HTML — it can also receive JSON, allowing users to reach different screens and different kinds of credentials. This allows the user to traverse the state machine through an authentication pattern dependent on their needs rather than the absolute state previously enabled.

By using these systems, the end-user and the associated application can then get an access token that it can use to call additional APIs or continue through their utilization flow. This entire process concludes with a normal OpenID Connect authentication response, making the complexity entirely hidden behind an exceptional user experience.

An Example Hypermedia Flow

Let’s take a look at an example flow. A simple application makes an authentication request using OpenID Connect, providing a client ID, a redirect ID, and some basic scopes. When this request is made, the client receives a representation of the states in the state machine. Since we’re using hypermedia, these representations don’t just reflect a simple username and password flow. They may represent various optional flows, metadata, templates, further actions, and other information.

Because the client has stated that it can understand these flow types, it receives all the types as optional flows. Let’s assume that we’re using a standard username/password pair for simplicity. In this case, we simply POST back to the server, and the server drives the state machine to the next stage. Here, the server provides complex state responses formulated in HTML that allows the user two inputs for username and password. Note that this is the same experience the user experienced in older systems, providing continuity of experience.

Next, the user logins and the entire state machine is complete. The user is authenticated, and links are sent back containing the callback URL, a type for the response, and an OAuth authorization code. The OpenID Connect code can be converted to an access token and refresh token for continued access and utilization.

This was a traditional flow. But let’s assume a more complex flow is needed. When the user receives the possible flows, let’s assume they select something like BankID. Since BankID is a login standard that is near-ubiquitous for Sweden, it is worth providing for APIs that service that region. When the user is given this flow, they see what the client renders from a response unit designed to connect to BankID. The actions provided also come with a stated request for additional information, and when the user receives this, they are prompted with an autostart token.

This autostart token essentially tells the client “we are using BankID, and your machine needs this app or custom scheme to use it”. Once the client receives this, the flow continues, and the BankID login system is launched. From here, the user can authenticate, and the rest of the flow is essentially as if they had used a password and username pair.

This is a great example of the kind of effectiveness enabled by this solution. To the user, there was very little difference between each flow, but the flows on offer were very different on the backend and resulted in fundamentally different systems being utilized. This makes for simplicity at the client and user sides but additional complexity with a clear value proposition for the server.

Attestation and Security

There is one problem with this solution. By moving the power to the client to determine flow and purpose, we are giving it quite a bit of power. To make this safe and secure, we need to know that we can trust the client and that the client is who we think they are. We can do this through something called attestation. In order to attest that this is the client in question, we need to prove the client’s actual identity.

This can be done through various methods, but one popular way is utilizing mobile phones. Mobile phones are basically smart cards, with private keys that have trust roots that go all the way to Apple, Google, and Microsoft. The trust root can be utilized to collect data about the client that is authenticating for these devices. We can use these roots to determine if the device is rooted, if it’s been securely booted, and even if it has a certain application ID that determines whether or not the client is a first or third-party application.

More importantly, we can use the server to take some power back and provide different flows depending on the value of the application ID. For instance, if the application ID points towards a third-party application, we can respond with a specific flow that requires additional authentication and checks. For first-party applications, we may be willing to trust the client, and thus can use a more liberal flow to allow access. Notably, we can also apply very different consent criteria, making both the flow and the acceptance states dependent on what application began the process.

Conclusion

Passwords are easy to collect, verify, and enter, but they come with a set of problems that make them challenging to trust. Hypermedia allows for a wider range of login methods while keeping the client simple. While it does bring more server complexity, it does so in a tradeoff for additional functionality and value. The user can log in with different methods through a better user experience. Not only are these existing flows made better, but future flows are also made possible, allowing for more innovation and value.

What do you think about using hypermedia to go passwordless? Is this the future of authentication? Let us know in the comments below!