vsmetamasklogin.yahoosites.com Open in urlscan Pro
67.195.197.33  Public Scan

Form analysis
0 forms found in the DOM

Text Content

LOGIN







ONE-CLICK LOGIN WITH BLOCKCHAIN: A METAMASK TUTORIAL

Online users are becoming increasingly resistant to traditional email/password
registration processes. One-click social login functionality via Facebook,
Google, or GitHub turns out to be a much more desirable alternative. However, it
comes with a trade-off.

Pros of social media login integration:

 * No more cumbersome form-filling.
 * No need to remember yet another username/password pair.
 * The whole process takes seconds instead of minutes.

Cons of social media login integration:

 * Since the user’s information is loaded from external providers, this raises a
   huge privacy concern on how providers use all this personal data. For
   example, at the time of writing, Facebook is facing data privacy issues.

This article introduces a new login method to blockchain development: A
one-click, cryptographically-secure login flow using the MetaMask extension,
with all data stored on our own back end. We call it: “MetaMask Login”.

How to Use Metamask for a One-Click Login Flow

The basic idea is that it’s cryptographically easy to prove the ownership of an
account by signing a piece of data using a private key. If you manage to sign a
precise piece of data generated by our back end, then the back end will consider
you the owner of that public address. Therefore, we can build a
message-signing-based authentication mechanism with a user’s public address as
their identifier.

Please note that while we will be using tools connected to the Ethereum
blockchain (MetaMask, Ethereum public addresses), this login process does not
actually need the blockchain: It only needs its cryptography functions. That
being said, with MetaMask becoming such a popular extension, now seems a good
time to introduce this login flow.


THE METAMASK BROWSER EXTENSION

If you already know what MetaMask is, feel free to skip this section.

MetaMask is a browser plugin, available as the MetaMask Chrome extension or
Firefox Add-on. At its core, it serves as an Ethereum wallet: By installing it,
you will get access to a unique Ethereum public address, with which you can
start sending and receiving ether or tokens.

But MetaMask Login does something more than an Ethereum wallet. As a browser
extension, it can interact with the current webpage you’re browsing. It does so
by injecting a JavaScript library called web3.js in every webpage you visit.
Once injected, a web3 object will be available via window.web3 in the JavaScript
code of this website. To have a look at what this object looks like, just
typewindow.web3 in the Chrome or Firefox DevTools console, if you have MetaMask
installed.

Web3.js is a JavaScript interface to the Ethereum blockchain. There are
functions to:

 * Get the latest block of the chain (web3.eth.getBlockNumber)
 * Check the current active account on MetaMask (web3.eth.coinbase)
 * Get the balance of any account (web3.eth.getBalance)
 * Send transactions (web3.eth.sendTransaction)
 * Sign messages with the private key of the current account
   (web3.personal.sign)

When MetaMask is installed, any front-end code can get access to all these
functions, and interact with the blockchain. They are called dapps or DApps (for
decentralized apps–sometimes even styled “ĐApps”).

Most functions in web3.js are read functions (get block, get balance, etc.),
andweb3 will give the response immediately. However, some functions
(likeweb3.eth.sendTransaction and web3.personal.sign) need the current account
to sign some data with its private key. These functions trigger MetaMask to show
a confirmation screen, to double-check that the user knows what she or he is
signing.

Let’s see how to use MetaMask for this. To make a simple test, paste the
following line in the DevTools console:

This command means: Sign my message, converted from utf8 to hex, with the
coinbase account (i.e. current account), and as a callback, print the signature.
A MetaMask popup will appear, and if you sign it, the signed message will be
printed.

A final note about this section: MetaMask injects web3.js into your current
browser, but there are actually other standalone browsers which also inject
web3.js, like Mist, for example. However, in my opinion, MetaMask offers today
the best UX and simplest transition for regular users to explore dapps.


HOW THE LOGIN FLOW WORKS

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
Logininstalled. 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:publicAddress
and 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 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 via web3.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 and
publicAddress.


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.


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.


WHY THE LOGIN FLOW WORKS

Authentication, by definition, is really only the proof of ownership of an
account. If you uniquely identify your account using a public address, then it’s
cryptographically trivial to prove you own it.

To prevent the case where a hacker gets hold of one particular message and your
signature of it (but not your actual private key), we enforce the message to
sign to be:

 1. Provided by the back end, and
 2. Regularly changing




We changed it after each successful login in our explanation, but a
timestamp-based mechanism could also be imagined.








Let us build and manage your beautiful seo-friendly website

Get Started