# 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](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP) for Sign-in with Ethereum in 2021, based on EIP-4361 ([ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)). The reference implementation of Sign-In with Ethereum by SpruceID ([SpruceID](https://spruceid.com) ) 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](/files/tabSEKUaSmS22HxVQ2Ae) A signature request with Metamask SIWE will look something like : ![Switchboard with SIWE](/files/crtPF0PGWLyDoJrUHXmG) *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](https://github.com/spruceid/siwe-oidc)), 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": ["/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:///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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.energyweb.org/legacy-documentation/ew-dos-technology-components-2023/identity-and-access-management-iam/iam-guides/sign-in-with-ethereum.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.