Acting on behalf of: separating the actor from the account in modern identity

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 most consumer and enterprise applications, the authenticated user and the account holder are treated as the same person. You log in, you see your data, you take actions on your own behalf. That assumption holds surprisingly often — but in a significant number of real-world scenarios it does not, and when it breaks down, the resulting experience tends to be either clumsy, insecure, or both.

In this post I will look at why separating the authenticated user from the account or entity they are acting within matters, what that looks like across a range of industries, and how Auth0 and Auth0 FGA address the two complementary sides of the problem. A follow-up post will cover a working demonstration I have built across six industry verticals.

The three-party model

Most identity literature talks about two parties: the user and the resource. Delegated access introduces a third.

• Actor: the authenticated user — the person who has logged in with their own credentials and whose identity has been verified.
• Subject / Represented party: the person, account, or entity on whose behalf the actor is operating. This may or may not be the same as the actor.
• Resource: the underlying account, record, subscription, or service being accessed — a patient record, a bank account, a family mobile plan.

When the actor and the subject are different people, we are in delegated access territory. The actor is real and verified; their authority to act on the subject's behalf is what needs to be established, scoped, and controlled.

This is not a new concept. Power of attorney in legal systems, next-of-kin access in healthcare, joint account holders in banking — these are all delegated access patterns that have existed for decades in the physical world. The challenge is that most digital identity systems were not designed with this pattern in mind, and organisations end up building workarounds that are fragile, opaque, and difficult to audit.

Where this shows up across industries

The delegated access pattern appears in almost every regulated industry. The details differ, but the underlying requirement is the same: one person needs to act within a context that belongs to someone else, with explicit and bounded authority to do so.

Healthcare. A patient grants their adult child access to view appointments and manage prescription repeats on their behalf. The child has their own login — they are not impersonating the patient — but they need to be able to act within the patient's record for specific purposes. Access may be time-bounded to a period of illness or recovery, and the patient must be able to revoke it at any point. The audit record needs to show not just what was done, but who did it and on whose behalf.

Financial services. A power of attorney needs to manage an elderly parent's savings account. A parent manages a child's investment account while the child can only view their balance. Spouses share control of a joint account. Each of these involves a different person with different permitted actions, different durability, and different revocation conditions. An approach that simply adds a "view other accounts" role to the user's profile does not capture any of this nuance.

Telecommunications. A family mobile plan has one account holder who owns the contract and manages billing, but each family member has their own login and their own usage. A teenager can view their own data consumption but not purchase add-ons without parental approval. The account holder can delegate billing administration to another adult on the plan without giving them full account ownership. These relationships are not static — they change as family circumstances change.

Streaming and media. A shared family subscription has multiple profiles attached to it. The subscription owner controls billing, but other family members can be granted administrative permissions over specific profiles or purchases. A child requests access to a pay-per-view event; the approval request goes to the parent or account administrator. Access to premium content is tied to the approval chain, not just to whether the user is authenticated.

Retail and subscription benefits. A household subscription pools benefits across multiple people. The subscription owner invites members who can use the benefits but not manage payment details. Usage needs to be tracked per individual, not per household, for analytics and for fraud detection. Members can be added and removed by account administrators without requiring those members to re-register or lose their own login history.

Case and complaint management. A legal practitioner lodges and manages complaints on behalf of a client. A family member assists an elderly relative with submitting a formal complaint. The delegate can view and act on the specific cases they were engaged to handle — but they must not be able to see every case associated with that client, because different cases may involve different legal representatives with different mandates. This is a particularly clear example of where relationship-based access is not optional: a role-based approach would either grant too much access or require a separate user account per case.

The common thread across all of these is that access needs to be explicit (the account holder consented to it), scoped (limited to specific actions on specific resources), auditable (the record shows who acted and on whose behalf), revocable (the account holder can withdraw it at any time), and often time-bounded (it expires when the underlying need expires).

Why role-based access control isn't enough

Role-based access control (RBAC) is the default approach in most identity systems, and it handles a significant range of access patterns well. A user is assigned a role — admin, billing-manager, viewer — and the role determines what they can do.

The problem with RBAC for delegated access is that it answers the wrong question. RBAC tells you what a user of type X can do. It does not tell you which specific records user X is permitted to act within on behalf of user Y.

If you give a carer the role of carer, you have established that they are a carer. You have not established that they are this patient's carer, that their authority covers appointments and prescriptions but not sensitive test results, that it runs until the end of this month, or that it can be revoked by the patient alone. All of that context lives outside the RBAC model, and organisations end up storing it in application code, in bespoke database tables, or simply not storing it at all.

The moment you need to answer the question "can user A act on behalf of user B for this specific resource, given the current time and the current state of their consent relationship?" — RBAC has run out of road.

Two complementary questions

Auth0 and Auth0 FGA are designed to answer two different but complementary questions, and the distinction matters.

Auth0 answers: who are you, and what are you allowed to do in general?

Auth0 handles authentication — verifying identity through Universal Login, managing sessions and tokens, enforcing MFA where required. It also handles the broad contours of authorisation: this user belongs to this application, these are their scopes, these are their high-level permissions. Auth0 is the right place for decisions that apply to the user globally and do not depend on a particular relationship to a particular resource.

Auth0 FGA answers: can this specific user, in this specific context, perform this specific action on this specific resource?

Auth0 FGA is a relationship-based access control (ReBAC) system built on OpenFGA. Instead of assigning roles to users, it stores explicit relationship tuples: user A has the relation delegate to resource B. Access decisions are evaluated by checking whether a relationship path exists in the model — can this user perform this action? — rather than by matching role assignments.

This is what makes it the right tool for delegated access. The relationships are stored as first-class data, not as application logic. They can be created, revoked, and inspected independently of the application. Time-bounded access can be enforced using conditional tuples that evaluate at check time, so a delegation that expires at midnight is denied at 12:00:01 without any scheduled job or polling loop needing to intervene.

The two systems complement each other naturally. Auth0 establishes and verifies the actor's identity. Auth0 FGA determines whether the actor's relationship to the subject and the resource justifies the action they are trying to take. Neither system is trying to do the other's job.

What good delegation looks like

When these two systems are used together for delegated access, the resulting model has some useful properties that are worth naming explicitly.

The actor is always themselves. They log in with their own credentials, pass their own MFA challenge, and are identified throughout the system as themselves. There is no shared login, no credential transfer, no impersonation.

The authority to act on another's behalf is explicit and recorded. It was granted at a specific time, by a specific person, for a specific purpose. It is not implied by a role or inferred from an organisational hierarchy.

The scope of that authority is bounded. A carer can view appointments and manage prescription repeats; they cannot access sensitive test results. A power of attorney can manage an investment account; they cannot change the account holder's identity details. The boundaries are part of the delegation record, not left to the application to enforce ad hoc.

The delegation is auditable. Every action taken under a delegated relationship is recorded with the actor (who performed the action), the subject (on whose behalf they acted), the specific resource, the decision outcome, and a reference to the delegation that authorised it.

The delegation is revocable. The account holder or their representative can withdraw consent, and the effect is immediate — the relationship tuple is removed and subsequent access checks will fail.

What's next

In the follow-up post I will walk through a working demonstration I have built using Auth0 and Auth0 FGA that implements this model across six industry verticals: healthcare, financial services, telecommunications, media and streaming, retail subscriptions, and case management. The same underlying authorisation engine handles all six — the verticals change the labels, the example data, and the specific resources, but the delegation lifecycle, the FGA relationships, and the audit trail are consistent throughout.