Why is "login with Ethereum" revolutionary?
Original title: "Why Sign-In with Ethereum is a Game-Changer - Part 1"
Original compilation: ETH Chinese
Original compilation: ETH Chinese
Sign-In with Ethereum (SIWE) revolutionizes user choices on the Internet.
Instead of having to compromise with some large middleman, users can now log in directly (without going through a middleman) using the same private key that controls their blockchain account. With SIWE, we open another path where big corporations can no longer deprive users of their ability to access services and 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) signature format for Ethereum accounts to securely authenticate any network-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.
Connecting to a wallet vs. logging in with Ethereum
The "Connect Wallet" button is the main function of dapp now. 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 about it. 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 via 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 have 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, and 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 a solution for maintaining state between the client and the server. Its basis is: when the client visits for the first time, the server generates a session id and returns it to the client. Of course, the server will also store the 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 to implement 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)
Carl uses dapps and has 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 something about him, 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 reauthenticates, 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.
Unify SIWE
Look across the Web3 landscape and you'll find many existing services offering some form of"Sign-In with Ethereum", but not many are 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 human-readable messages to users so they can understand what they are interacting with. In many cases, users see"LOGIN"(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:
Share Information - Share Interface
After agreeing on the signature message format, the application 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 that makes the user experience better and leaves no doubt about the actions the user is about to 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:
The specification also introduces additional security requirements for wallets, such as introducing domain bindings 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 the situation:
beyond authentication
SIWE information can also be understood as the authorization to access specific resources, or the delegation of session private keys to improve the functionality and ease of use of dapp UX. For example, imagine a world in which users can enrich their own sessions with data they retain, 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'll be posting part two of this article soon, so stay tuned! Until then, go implement SIWE!
