almost 3 years her

Let’s start with the how. The how will hopefully convince you that it’s secure, so I’ll keep the why part short.As stated in the overview, we will forget about the blockchain. We have a traditional Web 2.0 client-server RESTful architecture. We will make one assumption: That all users visiting our front-end web page have MetaMask Login installed. With this assumption, we will show how a passwordless cryptographically-secure login flow works.

Step 1: Modify the User Model (Back-end)First of all, our User model needs to have two new required fields:publicAddressand nonce. Additionally, publicAddress needs to be unique. You can keep the usual username, email, and password fields—especially if you want to implement your metamask login In parallely to an email/password login—but they are optional.The signup process will also slightly differ, as publicAddress will be a required field on signup, if the user wishes to use a MetaMask login. Rest assured, the user will never need to type their publicAddress manually, since it can be fetched viaweb3.eth.coinbase.

Step 2: Generate Nonces (Back-end)For each user in the database, generate a random string in the nonce field. For example, nonce can be a big random integer.

Step 3: User Fetches Their Nonce (Front-end)In our front-end JavaScript code, assuming MetaMask is present, we have access to window.web3. We can therefore call web3.eth.coinbase to get the current MetaMask account’s public address.When the user clicks on the login button, we fire an API call to the back end to retrieve the nonce associated with their public address. Something like a route with a filter parameter GET /api/users?publicAddress=${publicAddress}should do. Of course, since this is an unauthenticated API call, the back end should be configured to only show public information (including nonce) on this route.If the previous request doesn’t return any result, it means that the current public address hasn’t signed up yet. We need to first create a new account via POST /users, passing publicAddress in the request body. On the other hand, if there’s a result, then we store its nonce.

Step 4: User Signs the Nonce (Front-end)Once the front end receives nonce in the response of the previous API call, it runs the following code:This will prompt MetaMask to show a confirmation popup for signing the message. The nonce will be displayed in this popup, so that the user knows she or he isn’t signing some malicious data.When she or he accepts it, the callback function will be called with the signed message (called signature) as an argument. The front end then makes another API call to POST /api/authentication, passing a body with bothsignature andpublicAddress.

Step 5: Signature Verification (Back-end)When the back end receives a POST /api/authentication request, it first fetches the user in the database corresponding to the publicAddress given in the request body. In particular it fetches the associated nonce.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. metamask login

Step 6: Change the Nonce (Back-end)To prevent the user from logging in again with the same signature (in case it gets compromised), we make sure that the next time the same user wants to log in, she or he needs to sign a new nonce. This is achieved by generating another randomnonce for this user and persisting it to the database.Et voilà! This is how we manage a nonce-signing passwordless login flow.