The delegated-access series treated the authenticated login as the whole security principal. It isn't quite. The same real person routinely holds more than one login, and an authorisation model that can't tell them apart ends up merging blast radii it shouldn't.
Auth0 FGA
5 posts.
The previous post covered the CIBA approval flow for delegated access. This one covers what happens when the five-minute CIBA window closes before the approver responds - and why the answer reveals an important architectural distinction between the delivery mechanism and the approval itself.
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.
Identity systems are very good at answering one question: who are you? What they are less good at is the follow-up: and who are you acting for? In this post I will look at why separating the authenticated user from the account or person they are acting within is important, what it enables across a range of industries, and how Auth0 and Auth0 FGA address the two complementary sides of the problem.