On this article, we will explain a module we have built that, we think, facilitates and makes more transparent, to the end users, the authentication process of a web site that uses blockchain technology in any or another way.

The eruption of blockchain and the decentralized internet stresses the importance of security. In order to make the Dapps more secured, the Dapps designers make use of technology that somehow enforces the authentication process by adding more user confirmation steps (i.e. Metamask). The problem of this approach is that it makes the authentication process very complex to normal users and less transparent.

The technical requirements for making this work are:

1. Python 3.6 (libraries listed in requirements.txt)
2. Web3.js 1.0.0
3. Browserify ethereumjs_util  See this
4. Browserify eth-sig-util See this

The code is available here

The module manages the following processes:

SIGNUP PROCESS

1.The user needs to enter a password and, in the background, the application creates an ethereum account, encrypts this account generating a keystore, and puts this keystore in localforage (improved normal JS localstorage).

2.The ethereum account is then used as the login user name and sent to the backend authentication database. The important thing here is that the password doesn´t need to be sent over the network to the backend, making this process more secured.

3.The account is then entered into the backend authentication database and a json web token is sent back to the frontend so the session can be kept opened with no need to login again (the default expiration time of this token is 15 min but it can, of course, be changed)

4.The token is saved to localforage

SIGNIN PROCESS

 

1.On page load, the javascript first checks whether there is a token in localforage.

2.The endpoint “/gettoken” is a python flask function that has the decorator “@jwt_required”. This means that if the token is not valid, it can not even enter into the function. If the token is valid, it enters the function and a message and the account is sent back to the frontend in order to confirm that the token is valid

3.So, if the token is valid, the user does not need to sign in and is logged in automatically

4.If the token is not valid, the application:

a)Checks whether there is a keystore kept locally in localforage. If there is, it decrypts it, take the account, the private key, signs a text with the private key and sends the account and the signed text (signature) to the backend so it can be authenticated (Again, important to notice here that no password is send to the backend making the application more secured)

b)In the backend, it need to make sure the signature belongs to that account

3.If there is not keystore in localforage, the user will need to import a local wallet and the above process will be followed through

 

LOGOUT PROCESS

The token is entered into a revoked token table so it can not be used anymore