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

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.

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.

Requirements and Goals of the System

Functional Requirements:

  1. Eliminate the use of storing User Information
  2. Our service can be used by other applications both inside the network and as well as subscribers. Hence a Subscription feature is must.
  3. Limit the number of requests an entity can send to an API within a time window, e.g., 15 requests per second.
  4. 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.
  1. 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. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Orbit DeFi

Orbit DeFi

A one-stop platform that gives users a complete view of digital assets and tools to make great investment decisions.