“Sign-In with Ethereum” (SIWE) has revolutionized user choices on the Internet.
Users no longer have to compromise with some large middleman, and can now log in directly (without going through the middleman) using the same private key that controls their blockchain account. With SIWE, we have opened up another path where large corporations can no longer deprive users of their ability to access services and monitor their behavior.
SIWE is a fully public certification standard, achieved through open discussions with community members such as dapps, apps, wallets, security companies, and more. 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 providers (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 web-based service. SIWE is 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 discuss here what “login with Ethereum” means and how it goes beyond “connecting a wallet” for all the builders of Web3.
Connecting a wallet vs. logging in with Ethereum
The button “Connect Wallet” is now the main function of dapps. By clicking this button, the user begins the journey of interacting with Web3 and the 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 understand which account you want to use to interact with smart contracts, send cryptocurrencies, and even sign messages through dapps. The function of connecting to a wallet is very simple – the dapp has “no memory” of you, just a platform for simple interactions.
When the application wants to have richer contextual interactions with the user, such as loading the user’s 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. “Connected Wallet” does not provide this guarantee, but SIWE does. In other words, we need to authenticate users in order to establish a session with them and then securely read and write their data. To illustrate the difference, I gave the following two examples – Carl connecting the wallet and Sam establishing the session:
(Translator’s Note: Session is a solution used to maintain state between the client and the server. The idea is: When the client accesses 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 obtains 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 saved 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 operations only need to connect his wallet. Carl’s operation has been going well until one day, he encountered such a problem: he wants these dapps to remember some of his situation, so that when he uses these dapps for the third, fourth and fifth time , to give him a better experience.
Carl was thinking that if Uniswap could automatically import his liquidation preference, Aave could remember his favorite lending market, and even OpenSea could remember his name instead of 0x2Fe1a3… He would have a much better experience with accounts like this . Carl has to start 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 from where he left off, and the application still remembers everything about him. His information can even be kept in a remote database he controls.
Looking across the Web3 space, you’ll find that many existing services offer some form of “Sign-In with Ethereum”, but not many are up to the mark. They typically use it to establish a cookie-based session with the user that manages proprietary metadata about the account. For example, if you want to give users permission to customize their own profiles on your website (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 users with human-readable messages so they can understand what interactions they have had. In many cases, what the user sees is the word “LOGIN”, or some text that lets you log in, or even sometimes just an arbitrary number (here, sign this random crazy collection of letters and numbers) . Instead, we can identify a set of required fields based on existing practice, set up many good security measures, and a strict syntax that balances human readability and safe operation. Furthermore, wallets do not need to change their existing interfaces and practices, at least they can continue to provide users with this type of information.
First, we can take all this messy “SIWE” message and submit a request to the user in an acceptable and generic way:
Share Information – Share Interface
After agreeing on the signature message format, the application and wallet can now speak the same language. When an application submits a signature request to the user, the wallet can inspect the request, check that it matches EIP-4361 (SIWE) information, and let the user know that they are logging into a website.
At this point, the wallet can present a friendly stylized interface that makes the user experience better and does not cast any doubt on the actions the user is about to take. Instead of giving the user an arbitrary block of text to sign. The user now only has to click on a confirmation dialog to “log in” because the wallet “understands” the signing request. In order to achieve full transparency, the EIP-4361 specification states that all information and fields must still be available in other sub-interfaces (such as the detail view).
From the information in 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, users are further protected throughout the process. For example, if the wallet finds a valid SIWE message, but the user is signing example.com (but is actually at exampie.com), the wallet can warn the user of the situation:
SIWE information can also be understood as authorization to access specific resources, or 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 keep, rather than applications keeping users’ data. For more information, I highly recommend reading this article:
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/why-login-with-ethereum-is-revolutionary/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.