Diia.Sign for Business: Technical Challenges of Government Service Integration
ECDSA + SHA256 for hashing. Redis key mismatch between start and verify. QR code and deep link. Business data updates on every login. 4 fixes in 24 hours. A real integration story — unfiltered.
Diia.Sign for Business: Technical Challenges of Government Service Integration
A real story: how we integrated Diia.Sign and what went wrong (and how we fixed it).
Why Diia.Sign
Google OAuth is convenient but not legally significant. For a LegalTech platform, we need verified identity tied to tax ID / EDRPOU. Diia.Sign provides: verified identity, qualified electronic signature, QR code convenience.
Problem 1: ECDSA Hashing
Diia requires requestId signed with ECDSA SHA-256 in Base64. Minimal documentation. First attempt used simple SHA-256 hash (wrong). Fix: proper ECDSA sign with PEM private key.
Problem 2: Redis Key Mismatch
Different prefixes: diia:request: on start, diia:auth: on callback. Classic copy-paste bug. Callback arrived but Redis returned null. Fix: unified prefix constant.
Problem 3: Business Data Updates
First login created business records but subsequent logins skipped updates. Stale addresses and names. Fix: 4 PRs in 24 hours — UPDATE on every login with ON CONFLICT DO UPDATE.
Problem 4: Nginx Proto Override
Backend generated http:// redirect URLs behind Cloudflare/Nginx. Fix: X-Forwarded-Proto header + Express trust proxy.
Lessons
- Diia documentation is minimal — prepare for reverse engineering
- Redis keys must be constants — one prefix, one file
- Business data must sync on every login
- Test the full e2e flow — unit tests won't catch cross-component mismatches
- Configure Nginx headers before going to production
Registration: legal.org.ua