Auth Problem Looked Bigger Than It Was
5th February 2026
I spent most of this afternoon deep in the weeds designing an auth bridge between an existing cluster of servers and a new service used by the same clients base across the servers. The initial conversations went straight to the “big” answers—Cognito, full OAuth flows, external identity plumbing everywhere—and for a while it felt like the only responsible path was also the most complex one.Then, after nearly two hours, I realized what we really needed was a trusted issuer and a trusted verifier. We can use the existing platform to issue JWT bearer tokens from our user/client model, sign them with private keys we control, and let the new service verify them with public keys while enforcing claims like issuer, audience, scope, subject, and expiry.
Suddenly the design felt natural: no per-request callback to the issuer, no unnecessary moving parts, and clean attribution of every service call to a known user and client for metering and audit.
A good reminder that “production-grade” doesn’t always mean “maximal complexity”—sometimes the strongest design is the one that makes trust boundaries explicit and keeps the system understandable.
More recent articles
- I Passed My Driving Test - and And I Have Something to Say - 30th March 2026
- Microsoft Copilot and the MCP Integration Experience — A Mess - 16th March 2026
- WeChat -- The Worst Chatting App Ever Made - 7th March 2026