NewsFlash Articles Data Fundraising BlockBeats Pro

"Login with Ethereum" - Overturning the Choices of Internet Users

Read this article in 12 Minutes

Sign-In with Ethereum was built by the community with direct support from the Ethereum Foundation and ENS.

Original title: "Why Sign-In with Ethereum is a Game-Changer - Part 1"

Original author: Rocco

Original compilation: ETH Chinese

< p>

Sign-In with Ethereum (SIWE) revolutionizes user choices on the Internet.

Users no longer need to compromise with some large middleman, they can now log in directly using the same private key that controls their blockchain account (no need to go through a middleman ). With SIWE, we open another path where big corporations can no longer deprive users of their ability to access services, nor monitor their behavior.

SIWE is a fully open certification standard, achieved through open discussions with community members such as dapps, apps, wallets, security companies, etc. You can find all meeting minutes and notes on the website login.xyz. This approach is a far cry from the closed development of proprietary identity systems by tech giants or government vendors (protested by privacy and digital rights advocates).

In contrast, Sign-In with Ethereum (EIP-4361) defines an open creative commons (CC) for Ethereum accounts Signature format to securely authenticate any web-based service. SIWE was built by the community with direct support from the Ethereum Foundation and ENS, and Spruce took charge of the project late last year. I'm excited to be here to discuss what "logging in with Ethereum" means, and how it goes beyond "connecting wallets" for all builders of Web3.

Connect wallet vs. login with Ethereum

"Connect wallet "This button is now the main function of the dapp. By clicking this button, the user begins the journey of interacting with Web3 and blockchain.

By connecting the wallet, the app can know which account you are using; however, that's all. It's easier for your wallet to know which account you want to use to interact with smart contracts, send cryptocurrency, and even sign messages through dapps. The function of connecting to the wallet is very simple - the dapp has "no memory" of you, and just builds a platform for simple interactions.

When the application wants to perform richer contextual interactions with the user, such as loading user preferences or private chat messages, we first need to ensure that We are talking to the actual private key holder behind the account, not someone pretending to have control over the account. "Connect Wallet" does not provide such a guarantee, but SIWE can. In other words, we need to authenticate users in order to establish a session with them and then read and write their data securely. In order to illustrate the difference between the two, I gave the following two examples - Carl who connects to the wallet and Sam who establishes a session:

(Translator's Note: Session is in It is a solution to maintain state between the client and the server. Its idea is: when the client visits for the first time, the server will generate a session id and return it to the client. Of course, the server will also Store this session id in the memory. After the client gets the session id, it will send the session id back to the server in each subsequent request, so that the server can query its own memory to know that the client has visited. Session can be used Realize user login authentication. After the session id generated by the server is sent back to the client, it is often stored in a cookie, so Session-based authentication is also called Cookie-Based authentication. Source)

< p>Carl uses dapps and had a great experience. He can trade on Uniswap, borrow on Aave, and even buy NFTs on OpenSea. To perform these few operations, he only needs to connect his wallet. Carl's operation has been going smoothly until one day, he encountered such a problem: he wants these dapps to remember some of his situations, so that when he uses these dapps for the third, fourth and fifth time , can give him a better experience.

Carl is thinking, if Uniswap can automatically import his liquidation preference, Aave can remember his favorite lending market, and even OpenSea can remember his Name instead of 0x2Fe1a3... such an account, his experience will be much better. Carl starts from scratch every time he connects his wallet.

Sam would not have such a problem. After the Dapp authenticates it and establishes a session, the relevant information will be saved. Even if Sam disconnects and re-authenticates, the session continues where he left off and the application still remembers everything about him. His information might even be kept in a remote database he controls.

Making SIWE Unified

Look around in the Web3 space and you will find many existing services Offers some form of "Sign-In with Ethereum", but not much up to par. They typically use it to establish a cookie-based session with the user that manages proprietary metadata associated with the account. For example, if you want to give users permission to customize their own profiles on your site (like OpenSea does), you should authenticate users before they can make any changes, to ensure that only users can edit them own profile. The workflow is as follows:

The first step after connecting a wallet is to provide the user with a human-readable message so they can understand what they are interacting with. In many cases, what the user sees is "LOGIN", or some text that tells you to log in, or sometimes even just an arbitrary number (here, sign this random crazy collection of letters and numbers) . So instead, we can determine a set of required fields based on existing practices, put in place a lot of good security measures, and a strict syntax that balances human readability with safe operation. Furthermore, wallets do not need to change their existing interfaces and practices to at least continue to provide users with this type of information.

First, we can take all this messy "SIWE" information and submit requests to users in an acceptable generic way:

< p>

Shared Information - Shared Interface

After agreeing on the signed information format, the app and the wallet can now speak the same language . When an application submits a signing request to a user, the wallet can check that request, check that it matches the EIP-4361 (SIWE) information, and let the user know they are logging into a website.

At this point, the wallet can present a friendly stylized interface to make the user experience better without any doubt about the actions the user will take. Instead of giving the user an arbitrary block of text to sign. Users now only need to click a confirmation dialog to "log in" because the wallet "understands" the signature request. For complete transparency, all information and fields stated in the EIP-4361 specification must still be available in other sub-interfaces such as the detail view.

From the information of EIP-4361, we can get a clearer interface:

This specification is also The wallet introduces additional security requirements, such as introducing domain binding to prevent phishing attacks; introducing nonces to prevent replay attacks, and users are further protected throughout the process. For example, if the wallet finds a valid SIWE message, but the user is signing for example.com (but is actually at exampie.com), the wallet can warn the user of this situation:

In addition to identity verification

SIWE information can also be understood as authorization to access specific resources, or the delegation of session private keys to improve the functionality and functionality of dapp UX ease of use. For example, imagine a world where users can enrich their own sessions with data they persist, rather than applications saving the user's data. For more information, I highly recommend reading this article: "From Sign-In with Ethereum to Session Keys"

I will post the second part of this article soon, thanks Please pay attention! Until then, go implement SIWE!