Scale Enterprise Teams Securely with Roles for Auth0 FGA

TL;DR: The FGA Dashboard now supports roles with the release of the Per-Member Authorization feature. Account Owners can create groups, assign granular roles such as Group Manager, Store Editor, and Store Viewer, with the ability to scope access to individual stores. The best part? We built this feature using Auth0 FGA itself.

The "Super Admin" Problem

When your team first adopts FGA, granting every teammate full admin access via the dashboard is the easiest path to onboarding. With two or three engineers working on a single store, it just works.

Then adoption grows. Engineering spins up a staging store and a production store. The support team needs to look up authorization data to debug customer issues. An IT lead wants to onboard new members without accidentally granting them write access to production models. Suddenly, everyone being an admin isn’t a viable solution anymore. It’s a security risk.

This is the classic tradeoff between convenience and security. Granting everyone admin access is easy, but the Principle of Least Privilege says that every user should only have the permissions they need, and nothing more. The FGA Dashboard now gives you the controls to enforce that principle at scale.

What Is Auth0 FGA?

If you're new to Auth0 FGA, here's a quick primer. Auth0 FGA is a managed fine-grained authorization service built on OpenFGA, an open-source project inspired by Google's Zanzibar. It uses Relationship-Based Access Control (ReBAC), a model where access decisions are based on the relationships between users and resources, rather than static role hierarchies alone.

In practice, that means you define an authorization model that describes your system's objects, the relationships they can have, and how permissions are derived. You then write relationship tuples, which are simple facts like "user:alice is an editor of document:roadmap2026", and the FGA engine evaluates authorization checks against those relationships in real time.

This approach scales naturally from simple use cases (Can this user edit this document?) to complex ones that involve teams, hierarchies, shared resources, and conditional access.

Building an FGA Feature with FGA

Here's the part we're particularly proud of: Per-Member Authorization was built using Auth0 FGA. The FGA Dashboard now enforces its own permissions through the same authorization model and relationship tuples that you use to build authorization into your applications. When a Group Manager logs in and can only see the Groups tab, that decision flows through an FGA Check call, the same API your app calls when it asks "Can this user perform this action?"

This feature showcases how FGA's modeling language is expressive enough to handle a real-world, multi-role, store-scoped permission system, and that the engine is fast and reliable enough to gate every page load and API call in a production dashboard.

Members, Groups, and Scoping

Per-Member Authorization introduces three concepts to the FGA Dashboard: Members, Groups, and Store-Level Scoping.

Members

A member is any user who has been invited to your FGA account. Previously, every member had the same level of access. Now, each member's permissions are determined by the groups they belong to and the roles those groups carry.

Groups

A group is a named collection of members that shares a common role. Rather than assigning roles to individual users one at a time, you create a group, for example, "Dev Team" or "Security Ops", assign it a role, and then add members. Everyone in the group inherits the group's permissions automatically.

This design makes management at scale practical. When a new engineer joins, you add them to the "Dev Team" group and they immediately have the right access. When someone moves to a different team, you move their group membership and their permissions update accordingly.

Store-Level Scoping

Roles that operate on stores, Store Editor and Store Viewer, can be scoped to specific stores. This means a single group can grant its members Editor access to the "Staging" store and Viewer access to the "Production" store, or any combination that fits your workflow.

Scoping is what turns a basic role system into a genuinely fine-grained one. It lets you model real-world boundaries (development vs. production or team A's stores vs. team B's stores) without creating an explosion of roles.

The New Roles

The FGA Dashboard now supports four distinct roles, each designed around a specific responsibility:

Role	Scope	What It Can Do
Account Owner	Account-wide	Full administrative control. Manages the account, members, groups, and stores. This is the existing admin role, now renamed for clarity.
Group Manager	Account-wide	Creates and manages groups and their memberships. Can invite members to the account. Cannot access store data (models, tuples, or assertions).
Store Editor	Per-store	Modifies authorization models, writes and deletes tuples, and manages assertions within assigned stores. Includes Store Viewer capabilities.
Store Viewer	Per-store	Read-only access to store data. Ideal for support engineers, auditors, or stakeholders who need visibility without the ability to change anything.

The Group Manager role has an intentional constraint. Group Managers cannot assign roles with higher privileges than their own. A Group Manager can add members to groups and manage team composition, but they cannot grant Account Owner access or give themselves Store Editor capabilities. This separation of duties ensures that delegating team management doesn't create a path to privilege escalation.

Looking at the Authorization Model

Since we built this feature with FGA, let's look at a simplified version of what the authorization model looks like. If you've used Auth0 FGA or OpenFGA before, this will feel familiar. If you're new to it, this is a good introduction to how ReBAC models work.

In FGA, you define types (the kinds of objects in your system), relations (the relationships users can have with those objects), and then use those relations to derive permissions.

Here's a simplified snippet of the model powering the dashboard roles:

model
  schema 1.1

type user

type account
  relations
    define owner: [user, group#member]
    define group_manager: [user, group#member]

type group
  relations
    define member: [user]

type store
  relations
    define account: [account]
    define editor: [user, group#member]
    define viewer: [user, group#member] or editor
    define can_edit: editor
    define can_view: viewer

A few things to notice:

• The viewer relation on store includes editor, which means anyone who is an editor automatically has viewer access too. This is how the "Store Editor includes Store Viewer" behavior works, it's expressed directly in the model, not through application logic.
• Relations can reference group#member, which means "any user who is a member of the specified group." This is how group-based permissions flow through the system.
• Permissions like can_edit and can_view are derived from the relations above, keeping the Check calls clean and intention-revealing.

With the model defined, authorization data is written as relationship tuples. Each tuple is a simple fact with three fields: a user, a relation, and an object. For example, to make Alice a member of the "Dev Team" group and give that group editor access to the staging store, you would write these two tuples:

  # Alice is a member of the Dev Team group
  - user: user:alice
    relation: member
    object: group:dev-team

  # The Dev Team group has editor access to the staging store
  - user: group:dev-team#member
    relation: editor
    object: store:staging

When Alice tries to edit a model in the staging store, the dashboard calls the FGA Check API to ask: is user:alice an editor of store:staging? The answer is “yes” because Alice is a member of group:dev-team, and that group has the editor relation on store:staging.

That's ReBAC in action: the authorization decision follows the chain of relationships rather than looking up a static permission table.

Building More Roles

The four roles available today cover the most common patterns we've heard from customers, but they're just the foundation. Because this feature is built on FGA's own modeling language, adding new roles is a matter of extending the authorization model, not rewriting application logic.

Possible enhancements:

• Additional built-in roles: such as a Store Admin role that can manage store settings and membership without requiring full Account Owner access.
• Custom roles: the ability for you to define your own roles with a specific set of permissions tailored to your organization's needs.

Using Roles in Auth0 FGA

Per-Member Authorization is available now. Here's how to start using it:

1. Navigate to the Groups tab under Account > Groups in the FGA Dashboard.
2. Create a group for each team or function (e.g., "Engineering," "Support," "IT Ops").
3. Assign a role to each group, Group Manager, Store Editor, or Store Viewer, and scope store-level roles to the appropriate stores.
4. Add members to each group. They'll inherit the group's permissions immediately.
5. See the FGA Roles and Permissions documentation for all detailed steps.

If your team has been operating with everyone as an admin, this is a good time to audit your current members and move to a least-privilege model. Start by creating a group for your core engineering team with Store Editor access to the stores they work with, and a separate group with Store Viewer access for anyone who only needs to read data.

Per-Member Authorization brings enterprise-grade access control to the FGA Dashboard, built on the same technology you use to secure your own applications. Define your teams, assign the right roles, and let FGA enforce the boundaries.

Get started in the FGA Dashboard →