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.
Delegated Access with Auth0 and Auth0 FGA
4 parts, in order.
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.
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 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.