Swift Auth — Cross-Trust Paywall Bypass
The hard part of replacing AWS Pinpoint for an 11-site newspaper network wasn't sending 1.5 million emails a year — the serverless send platform is the same one I later generalized and open-sourced as Addressium. The genuinely novel piece was access control: proving, on the morning-burst hot path, that a reader who taps a story in their mail app is allowed past the paywall — where the proof crosses out of my service and into someone else's WordPress plugin, on someone else's box, with no time for a database lookup. I owned the requirements and drove the architecture; an AI coding agent implemented under my direction.
- A two-token model that trusts asymmetrically. The email carries a symmetric HMAC token to my own redirector (it never leaves my walls, and carries everything the click needs, so there's no lookup). The redirector then mints a short-lived Ed25519 grant that the WordPress plugin verifies in-process with only the public key — no shared secret, no callback, no network call while the reader waits.
- Designed to the "what if they own this box" question. I kept pushing the agent on one threat model until the answer was acceptable: if a WordPress box is popped, the attacker can read articles and check tokens, but cannot forge a bypass, send an email, or read a single subscriber — because the private key and the subscriber data were never on that side of the line.
- Cut my own plan when the numbers didn't back it up. I'd planned to cache the suppression store for latency. Once I ran the numbers — seconds and about a cent per send directly, versus forcing every send worker into a VPC — the cache didn't pay for itself, so I dropped it. Owning the tradeoff means reversing it when the data says so.
HMAC · Ed25519 · Lambda · WordPress plugin · TypeScript · AWS CDK


