EIP-4361 (Sign-In with Ethereum)

The core of SIWE is a standardized, human-readable sign-in message that a user signs with their private key. This message includes essential fields like:

• Domain: The website requesting the signature.
• Address: The user's Ethereum address.
• Statement: A plain-text declaration of intent (e.g., 'I accept the Terms of Service').
• Nonce: A random value to prevent replay attacks.
• Expiration: A timestamp for message validity. This structured format prevents phishing and ensures the user knows exactly what they are signing.

The authentication process follows a specific sequence:

1. Challenge: The service (relying party) presents the user with a formatted SIWE message.
2. Signing: The user's wallet (e.g., MetaMask) displays the message for review and prompts for a signature using their private key.
3. Verification: The service verifies the cryptographic signature against the user's public address and validates all message fields (domain, nonce, expiration).
4. Session Establishment: Upon successful verification, the service creates an authenticated session for the user. This flow eliminates the need for passwords or third-party OAuth providers.

SIWE incorporates multiple security mechanisms to protect users:

• Domain Binding: The message is cryptographically bound to the service's domain, preventing a malicious site from using a signature intended for a legitimate one.
• Human-Readable Messages: Users can visually verify the exact statement, URI, and expiration before signing.
• Nonce Management: Servers track used nonces to block signature replay attacks.
• No Secret Storage: Authentication relies on a signature, not a shared secret (like a password) that can be leaked from a server database.

SIWE enables self-sovereign identity (SSI), where users control their digital identity without relying on centralized authorities. Key principles include:

• Portability: The same Ethereum identity can be used across any compatible service.
• Censorship Resistance: No central provider can revoke or deny access to the identity.
• Minimal Disclosure: Users can choose to reveal only their public address or can link to verifiable credentials (like NFTs or attestations) to share specific attributes without exposing personal data.

SIWE is designed to integrate seamlessly with common web development and blockchain tools:

• Wallet Integration: Supported natively by major wallets like MetaMask, Rainbow, and Coinbase Wallet.
• Backend Libraries: Official libraries exist for Node.js, Python, Go, and other languages to handle message generation and verification.
• Session Management: Works with standard web session tokens (JWT, cookies) after signature verification.
• ERC-1271 Support: Can verify signatures from Smart Contract Wallets, allowing contracts to sign in on behalf of users.

While primarily for authentication, the SIWE standard enables more advanced applications:

• Terms of Service Acceptance: The signed statement can serve as a legal record of consent.
• Delegated Authority: A signature can authorize a specific action (like a transaction) without giving full wallet access.
• Cross-Service Reputation: A user's on-chain history and credentials become part of a portable reputation system.
• Gated Content/DAO Access: Authentication can be combined with token/NFT ownership checks for permissioning.

SIWE uses a structured sign-in message that users sign with their private key. This message includes critical security parameters like the domain name, a statement of intent, a nonce, and an expiration time. The resulting Ethereum Signed Message signature is verified on the backend, proving the user controls the address without needing passwords or third-party providers.

The protocol shifts control to the user by eliminating reliance on centralized identity providers. Key benefits include:

• No Password Management: Authentication is tied to the user's cryptographic keys.
• Reduced Phishing Risk: The signed message is explicitly scoped to a specific domain.
• Portable Identity: The same Ethereum address can be used across any SIWE-compatible service, creating a unified, user-controlled identity layer.

Integrating SIWE requires backend verification libraries (e.g., siwe for various languages) and frontend wallet interaction. Major wallets like MetaMask, Rainbow, and Coinbase Wallet support the standard, often providing a streamlined UX for signing SIWE messages. The process typically involves generating a nonce, presenting a message to sign via eth_signTypedData_v4, and validating the signature server-side.

SIWE is foundational for applications prioritizing user ownership and interoperability:

• Web3 DApps & DAOs: For gated access, voting, and reputation systems.
• Developer Platforms: Services like Vercel and Fleek use it for account management.
• NFT Communities: Gating content or forums based on token ownership.
• Decentralized Finance (DeFi): Streamlining onboarding and layering identity onto financial interactions.

EIP-4361 originated as an Ethereum Improvement Proposal (EIP). Upon finalization and adoption, it was assigned the ERC-4361 identifier, categorizing it as an application-level standard. This dual naming reflects its journey from proposal to a formalized standard for Ethereum application developers.

Secure implementation is critical. Essential practices include:

• Strict Domain Binding: Enforcing that the message's domain matches the server's domain to prevent replay attacks.
• Nonce Management: Using strong, server-generated nonces to ensure message freshness.
• Message Expiration: Implementing short-lived validity periods for sign-in messages.
• Avoiding personal_sign: Preferring eth_signTypedData_v4 for its explicit, structured data formatting.

The domain field in the SIWE message binds the signature to a specific website origin. Browsers and wallets must display this domain prominently to users. Best practices include:

• Strict Origin Matching: The requesting site's origin must exactly match the domain field.
• Subdomain Security: Define a policy for subdomains (e.g., *.app.example.com).
• User Education: Wallets should warn users if the displayed domain differs from the expected service. This prevents phishing sites from tricking users into signing valid messages for attacker-controlled domains.

Secure server-side session management is critical. The nonce is a server-generated, cryptographically random string that must be:

• Unique per session to prevent signature replay.
• Stored securely on the server before the signing request.
• Verified immediately upon receiving the signed message.
• Invalidated after use. Using a timestamp alone is insufficient. Best practice is to combine a nonce with a short expiration time (e.g., the expiration field) to limit the attack window.

Wallet developers play a key role in security. Wallets should:

• Display a clear human-readable preview of the SIWE message, highlighting the domain, resources (requested permissions), and statement.
• Warn on mismatches between the SIWE domain and the site's visible URL.
• Implement secure signing contexts to prevent malicious dApps from spoofing the signing interface. A poor UX can lead to signature blindness, where users approve messages without reviewing them.

The resources field in SIWE allows users to see what data or permissions the application is requesting. Security best practices include:

• Explicit Scoping: Applications should request the minimum necessary resources (e.g., specific NFTs, token balances).
• User Consent: The list must be displayed clearly in the wallet.
• No Implied Permissions: A SIWE signature for authentication should not be misinterpreted as authorization for financial transactions. Separate signatures should be required for sensitive actions.

The core of SIWE is a human-readable message defined by the EIP-4361 specification. This message includes key fields like:

• Domain: The service requesting the signature (e.g., example.com)
• Address: The Ethereum address proving ownership
• Statement: A text the user agrees to (e.g., 'I accept the Terms of Service')
• URI: The resource identifier (e.g., https://example.com/login)
• Version, Chain ID, Nonce, Issued At: Security and versioning parameters. This structured format prevents phishing attacks by making the sign-in intent explicit and verifiable.

SIWE is primarily an authentication protocol. It answers the question: "Does this user control this Ethereum address?" It is distinct from authorization, which determines what the user is permitted to do after logging in. While the SIWE message can include requested resources (like resources: [{'https://example.com/profile': 'read'}]), granting those permissions is a separate step. This separation aligns with the principle of least privilege and allows for flexible session management and access control systems to be built on top of the proven identity.

SIWE messages are signed according to ERC-191, the standard for signed data with a version byte and intended validator. The SIWE message is prefixed with the string \x19Ethereum Signed Message:\n plus the message length, then hashed. This prevents signatures from being valid Ethereum transactions (replay protection). Understanding ERC-191 is crucial for developers implementing signature verification, as it's the underlying mechanism that makes SIWE signatures cryptographically verifiable and domain-bound.

After successful SIWE authentication, a backend service typically issues a session token, often a JSON Web Token (JWT), to maintain the user's logged-in state. The JWT is signed by the server and can contain claims like the user's Ethereum address and session expiry. This pattern mirrors traditional web auth flows but with a decentralized first step. The SIWE signature itself is not the session token; it's the one-time proof used to obtain one, preventing the need to sign a message for every request.

SIWE is a foundational component for implementing Decentralized Identifiers (DIDs) on Ethereum. A DID is a portable, verifiable identifier controlled by the user. An Ethereum address can serve as a DID (e.g., did:ethr:0x...). The SIWE signature is a verifiable presentation that proves control of that DID. This enables a wider SSI (Self-Sovereign Identity) ecosystem where users can collect and present verifiable credentials (like attestations or proofs) linked to their Ethereum-based identity, beyond simple sign-in.