Solutions Engineer at Okta. I write about identity, access management, and security. This site archives my published articles, talks, and presentations.
The previous post covered how a patient proactively grants a carer access to their record. This post covers the inverse: a user requests access they do not yet have, and the account holder approves it in real time using Auth0's Client-Initiated Backchannel Authentication.
The first post in this series covered why separating the authenticated actor from the account they are acting within matters. This post covers how to build it: the data model, the integration points between Auth0, Auth0 FGA and a standard application data store, and the key flows from delegation grant through to acting on someone else's behalf.
Auth0 gives you a lot of knobs to turn when it comes to sessions and tokens — enough that the choices start to blur together. This post maps out every option, what it does, when you'd reach for it, and how they work together for different application types.
Every Vendor Security and Customer Requirement Questionnaire asks the same questions — the SIG words them one way, CAIQ another, HECVAT a third. The standard approach is to re-derive answers from scratch each time. The better approach is to treat this as a retrieval problem: build a canonical corpus of approved answers once, and match new questions to it.
The original analytics implementation stored one tiny file in Vercel Blob for every page view. Vercel Blob charges per operation, not per byte, so this burned through the free tier faster than expected. In this post I will detail the migration to Firestore daily summary documents — one write per page view, one read per day of stats — and the Firestore gotcha that wasted an afternoon.