In this first post we will address the possibility of using the Metamask extension to authenticate a user of a Blazor WASM (Web Assembly) application. We immediately describe the architecture used.

A Blazor Web Assembly application is installed on the Browser in which some pages are subject to authentication. The Metamask extension is also installed on the browser (Chrome was used). When Metamask is installed, the window.ethereum object is injected into the DOM (the window.web3 object is no longer injected starting from January 2021) through which to interact with the functions made available to Metamask. The Blazor application will also interact with Metamask’s Javascript API. We will see it shortly. the last component is a .NET Core API server which functions as a Token provider and data provider. The database containing the data for user registration and authentication has the following simple structure:

Associated with each user there are both the Blockchain address present in Metamask, and a Nounce that will be used to verify the user’s identity. This Nounce is nothing more than a complex and random alphanumeric string that changes for each access. Associated with each user there are both the Blockchain address associated in Metamask, and a Nounce that will be used to verify the user’s identity. This Nounce is nothing more than a complex and random alphanumeric string that changes for each access. The first nounce is generated upon registration.

The processing flow for user authentication involves all three parties and has the following timeline:

the Blazor application has a landing page containing a button to access a page subject to authentication.

Once the button is clicked there will be a redirect on the Login page. It is with this page that we begin to interact with Metamask.

A check is made to check if Metamask is installed on the browser and if the extension is present then i try to connect (1).

At this point (2) once we have recovered the address of the associated account in Metamask, we send this address to the server which will return (if the address has been previously registered) the user’s Nounce (3). Again thanks to the Metamask API, the Blazor application asks Metamask to sign the nounce received from the server. Authorization to sign is requested (4)

and the signed nounce is returned (5). At this point we send two pieces of information to the server: the nounce and the signed nounce.

The server uses Nethereum features to verify the signature. The function used returns the address corresponding to the signature. It looks for the address in the databases and the corresponding nounce. If they coincide, we are sure that whoever signed the nounce is our user (in possession of the relative private key in his Metamask wallet).

At the end of the check, if the result is positive, an object of type User is returned which also contains the Token e si genera un altro nounce per la successiva autenticazione. The User type object is serialized and stored in the Localstorage of the application where it is retrieved every time it is necessary to access a page subject to authentication. The login page code redirects the flow to the original page that requested a token to access it.

In the next posts we will go into detail on some implementation aspects and we will take a closer look at both the Blazor side code and the server code that generates the tokens and provides the data to the client side.