User Authentication: A journey from old RESTFUL to Decentralized system.

Password based authentication is an insecure approach to online transactions.

Multi-factor schemes add more friction that reduce user adoption and productivity. New data privacy laws and regulations act as minefields of security and customer experience issues that are costly and ineffective.

What is Decentralized Authentication?

Our research project, at Saren explores the business applicability of self identity initiative using Metamask. The users in this effort share a common interest in validating by example the self-sovereign identity vision. Our multi-phased project iterates on several scenarios involving the use of verifiable credentials in online authentication and authorization activities.

It is a simple cryptographically signed authentication flow using a wallet extension.

This article highlights the first phase of our joint research journey where we focused on verifiable credentials as an alternative to the universal frustrations of user IDs and passwords.

Why do we need Decentralized Authentication System?

Innovation is a process of creativity of new concepts that, when forged together, offer better solutions that meet new requirements or existing market needs. Such endeavours follow an iterative journey of trials and errors where lessons are learned and applied towards an eventual solution.

Expectations are now on the rise for blockchain-based decentralized identity solutions. Through the prism of the Metamask, industry chatter surrounding the emerging technologies associated with decentralized identity suggests that media interest is ripe for breakthrough evidence of business applicability.

Requirements and Goals of the System

Functional Requirements:

1. Single-Click Authentication and Authorization.
2. Eliminate the use of storing User Information
3. Our service can be used by other applications both inside the network and as well as subscribers. Hence a Subscription feature is must.
4. Limit the number of requests an entity can send to an API within a time window, e.g., 15 requests per second.
5. The APIs are accessible through a cluster, so the service should be considered across different servers. The user should get an error message whenever the defined threshold is crossed within a single server or across a combination of servers.

Non-Functional Requirements:

1. The system should be highly available. The service should always work since it protects our service from external attacks.
2. Our services should not introduce substantial latencies affecting the user experience.

How to do Single Sign In Authentication?

We are used to traditional systems, similarly we don’t know much about Blockchain systems. At Saren, we have successfully developed a login system that allows for a better decentralised web experience. Below is a brief overview of our new system that explains step-by-step through each action that takes place during authentication.

1. User Entity Schema changes: User schema needs to have two new required fields: publicAddress(primary key) and nonce(Number used once which is unique).One can keep the usual fields, spending on the requirement but they are optional.
2. Nonce Generation: Whenever a user is created in a database, generate a random string in the nonce field. For example, nonce can be a big random integer.
3. User Fetches Their Nonce (Front-end): Client side code fetches nonce from backend with respect to that user, as soon as the login button is clicked assuming MetaMask is present, access the window.web3. Call is made to web3.eth.coinbase to get the current MetaMask account’s public address. If the backend doesn’t return any result, it means that the current public address hasn’t been signed up yet. Hence the registration process starts.
4. User Signs the Nonce: As soon as the client side receives nonce, an event is triggered i.e web3.personal.sign(nonce, web3.eth.coinbase, callback), prompting MetaMask to show a confirmation popup for signing the message. The nonce will be displayed in this popup for the user to know it isn’t signing any malicious data.
5. Signature Verification on Server-Side: Having the nonce, the public address, and the signature, the back end can then cryptographically verify that the nonce has been correctly signed by the user. If this is the case, then the user has proven ownership of the public address, and we can consider her or him authenticated. A JWT or session identifier can then be returned to the front end.
6. Change the Nonce: To prevent the user from logging in with the same key, it is made sure whenever a new request comes a fresh signature is delivered.

More Saren News?

Our decentralised forum is currently in its final stages of development. Unfortunately, due to many bugs it has been delayed and we will have news soon about a concrete date of launch.

Moving forward we will be creating a telegram channel with all development updates there. As there can be a lot of noise in the Original telegram chat, we consider it the right move as many great projects have chosen this approach over a standard telegram group.