INTERMEDIATE⚙ Go Backend2-3hMilan

SIWE Auth Server

Build a Go HTTP server implementing Sign-In with Ethereum (EIP-4361). Users connect their wallet, sign a nonce-bearing message, and receive a JWT. This is the exact auth pattern Gnosis Pay uses for their B2B2C partner API.

Tech Stack

Gonet/http or chigo-ethereum/cryptoJWT (golang-jwt)SIWE message parsing

What You'll Learn

→EIP-4361 (SIWE) message format and verification
→Ethereum signature recovery (ecrecover in Go)
→Nonce management to prevent replay attacks
→JWT issuance and middleware-based auth
→Clean HTTP handler patterns in Go

Milestones (0/4)

M1Nonce endpoint & SIWE message construction

▾

M2Signature verification & address recovery

▾

M3JWT issuance

▾

M4Rate limiting & cleanup

▾

Architecture Hints

Architecture

Client (wallet)
    │
    ├── GET /siwe/nonce → receives random nonce
    │
    ├── Signs SIWE message with wallet (MetaMask/WalletConnect)
    │
    ├── POST /siwe/verify {message, signature}
    │       ├── Parse SIWE message → extract address, nonce
    │       ├── Validate nonce (exists, not expired, one-time)
    │       ├── ecrecover → verify signer == claimed address
    │       └── Issue JWT → return to client
    │
    └── GET /me (Authorization: Bearer <jwt>)
            └── Middleware validates JWT → returns address

Key design decisions: - Nonces are one-time-use to prevent replay attacks - JWT is stateless — no session store needed - Rate limiting on nonce endpoint prevents DoS - SIWE message format follows EIP-4361 exactly

Interview Talking Points

▸Explain how SIWE differs from traditional username/password auth and why it's better for Web3
▸Discuss nonce management — why one-time use, why expiry, race conditions with concurrent requests
▸Talk about JWT vs session-based auth trade-offs in a microservices context like Gnosis Pay
▸Mention how this pattern maps to Gnosis Pay's B2B2C partner API authentication