Consent Management
A privacy-first pattern for collecting, storing, and honoring user consent across sessions with cryptographic integrity guarantees.
Overview
Modern applications must track granular consent — analytics, marketing, functional cookies — while proving the consent record hasn't been tampered with. This recipe combines a client-side consent banner with a server-side HMAC-signed consent ledger stored in Upstash KV, giving you an auditable trail that survives cookie wipes and browser migrations when the user is authenticated.
Architecture
- Consent Banner — rendered via a client component that reads initial state from a server cookie, then hydrates interactively.
- Server Action — accepts the user's choices, signs the payload with HMAC-SHA256 using a rotating key, and persists to KV.
- Middleware — reads the consent cookie on every request and attaches a parsed consent object to the request context so downstream handlers can gate third-party scripts.
Key Decisions
- HMAC over JWT — consent records are immutable ledgers, not session tokens. HMAC with a server-held secret avoids client-side tampering without the overhead of asymmetric signing.
- KV TTL — consent entries expire after 400 days, matching the upper bound recommended by most privacy frameworks. The cookie itself carries a shorter 90-day TTL to prompt periodic re-affirmation.
- Anonymous path — unauthenticated users get a random consent ID stored in an httpOnly cookie. Authenticated users have consent keyed to their account UUID, surviving device changes.
Next Steps
Read the full implementation guide with copy-paste code blocks in the docs. Pair this recipe with the audit log recipe for a complete privacy-compliance pipeline.
Meridian tip: Use the consent ledger as an input to your CDN edge rules — strip third-party analytics scripts at the edge when consent is absent, before a single byte hits the browser.