Sign-In with Ethereum

Sign-in with Ethereum (SIWE) is an open standard for decentralized authentication that allows users to sign in to websites and applications using their Ethereum accounts. Unlike traditional centralized authentication methods, this innovative approach allows users to access various online services and applications using their Ethereum wallet address and cryptographic keys. This groundbreaking login solution represents a significant step forward in the evolution of decentralized identity management, empowering users with enhanced privacy and ownership of their digital identities.

Why SIWE?

The Ethereum Foundation and Ethereum Name Service (ENS) had put forward a Request for Proposal for Sign-in with Ethereum in 2021, based on EIP-4361 (ERC-4361: Sign-In with Ethereum). The reference implementation of Sign-In with Ethereum by SpruceID (SpruceID ) provides an easy integration with Application’s Identity services and assures smooth Sign-In user experience. It has numerous benefits over other PKI based signatures, such as :

1. A standard human readable verifiable message to confirm signatures.

2. An EIP-standard message schema to incorporate all the information needed for a secure authentication.

3. Verification for domain and uri, this assures the authenticity of the requester / verifier. Users can validate the domain the transaction was initiated from and the URI to which the access would be provided to (redirection) upon signing for authentication / authorization.

4. Preventing replay attacks with a nonce, which could be a challenge from a server or a random token .

SIWE message template

${domain} wants you to sign in with your Ethereum account:
${address}

${statement}

URI: ${uri}
Version: ${version}
Chain ID: ${chain-id}
Nonce: ${nonce}
Issued At: ${issued-at}
Expiration Time: ${expiration-time}
Not Before: ${not-before}
Request ID: ${request-id}
Resources:
- ${resources[0]}
- ${resources[1]}
...
- ${resources[n]}

Message Field Descriptions

authority is the RFC 3986 authority that is requesting the signing. address is the Ethereum address performing the signing conformant to capitalization encoded checksum specified in EIP-55 where applicable. statement (optional) is a human-readable ASCII assertion that the user will sign, and it must not contain '\n' (the byte 0x0a). uri is an RFC 3986 URI referring to the resource that is the subject of the signing (as in the subject of a claim). version is the current version of the message, which MUST be 1 for this specification. chain-id is the EIP-155 Chain ID to which the session is bound, and the network where Contract Accounts must be resolved. nonce is a randomized token used to prevent replay attacks, at least 8 alphanumeric characters. issued-at is the ISO 8601 datetime string of the current time. expiration-time (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message is no longer valid. not-before (optional) is the ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid. request-id (optional) is an system-specific identifier that may be used to uniquely refer to the sign-in request. resources (optional) is a list of information or references to information the user wishes to have resolved as part of authentication by the relying party. They are expressed as RFC 3986 URIs separated by "\n- ".

Sample SIWE Message :

switchboard-dev.energyweb.org wants you to sign in with your Ethereum account:
0x09622D91d6aA98385f40D3D0713BaA66baF3281A


URI: https://identitycache-dev.energyweb.org/v1/login/siwe/verify
Version: 1
Chain ID: 73799
Nonce: wRiKroUIa9LuYWWeG
Issued At: 2023-03-07T09:07:46.050Z

Given all these advantages, Sign in with Ethereum proved to be an ideal choice for Energy Web in implementing authentication for our decentralized applications (DApps). Authentication with SIWE is supported by our Passport strategy (available in passport-did-auth from v2.0.0 ).

How it works?

SIWE Authentication

A signature request with Metamask SIWE will look something like :

Switchboard with SIWE

Note: The text block in the above MetaMask pop-up for signing is the SIWE message.

Major security considerations for SIWE

Preventing replay attacks

• During each session initiation, it is crucial to select a nonce with sufficient entropy to thwart replay attacks – a type of man-in-the-middle attack where an adversary intercepts the user's signature and uses it to initiate a new session on their behalf.

• To ensure security, implementers have the option to utilize privacy-preserving but readily accessible nonce values. For instance, they may consider using a nonce derived from a recent Ethereum block hash or a recent Unix timestamp. These methods offer a balance between safeguarding privacy and ensuring widespread applicability.

Verification of domain binding

• Wallets are required to verify that the domain aligns with the actual source of the signing request.

• It is recommended to cross-check this value with a trusted data source, such as the browser window, or through another reliable protocol. By doing so, wallets can enhance security and mitigate potential risks associated with fraudulent or unauthorized signing requests.

SIWE with Federated Identity service

Many organizations aim to deploy a unified Identity Service that can be utilized across all federated services, employing OpenID Connect for efficient user session management. Thanks to SIWE-OIDC (OpenID Connect Identity Provider for Sign-In with Ethereum), this objective has now become achievable.

Current scope for SIWE-OIDC

SpruceID has deployed an OpenID Connect Provider (OP) which has support for SIWE and hosted under SIWE Open ID Connect . This deployment is a DAO-governed OP supported by ENS DAO.

To use the hosted OIDC server it is required to register the application as an OIDC client using the OIDC client registration of SIWE Open ID Connect . Currently, no user interface for OIDC client registration is supported. For that reason, developers will need to use the REST API.

curl -X POST https://oidc.signinwithethereum.org/register
   -H 'Content-Type: application/json'
   -d '{"redirect_uris": ["<https://<your.comaind>/cb"]}'>

The following is an example response:

{
"client_id": "9b49de48-d198-47e7-afff-7ee26cbcbc95",
"client_secret": "er...",
"registration_access_token": "2a...",
"registration_client_uri": "https://oidc.signinwithethereum.org/client/9b49de48-d198-47e7-afff-7ee26cbcbc95",
"redirect_uris": ["https://<your.domain>/cb"]
}

A client can then be updated or deleted using the registration_client_uri with the registration_access_token as a Bearer token. The authentication could be similar to

Note : This flow is just a possible flow, it could be different for a different use case.

Apart from the existing functionalities offered by SIWE, there is potential for future extensions, including support for Decentralized Identifiers and Verifiable Credentials, as well as integration with EIP-712 for Type structured data hashing and signing.