Roles

Roles in FusionAuth are associated with an application. You can define as many roles as you want in an application. There are no limits on the number of roles a user or a group can have.

Roles are application specific and may be specific to the domain of the application. Roles are typically used by APIs and applications to control access to functionality. For example, Zendesk presents a different user interface to users with the agent role than to users without that role.

For a further example, an e-commerce application may have the following roles:

• admin
• seller
• shopper

On the other hand, a content management system may have these roles:

• admin
• editor
• contributor
• subscriber

Roles are available in the JWT upon successful authorization and are also returned as part of the user's registrations.

You can associate roles with users directly via their registration. Or you can assign an application role to a group, and then any users in that group who have access to that application will have that role.

Core Concepts Relationships#

Below is a visual reminder of the relationships between FusionAuth's primary core concepts.

Role Attributes#

Roles in FusionAuth have the following attributes:

FusionAuth Admin UI Roles#

FusionAuth provides an administrative user interface for the running instance with several built-in roles. These can be assigned to any user registered with the FusionAuth admin application. These roles control access to functionality within the FusionAuth administrative user interface.

Below you can see a user's registration in the FusionAuth application, with their assigned admin role.

/admin/user/manage/00000000-0000-0000-0000-100000000001

Role Schema and Exceptions#

The table below outlines how admin UI roles were designed at an abstract level. Of course, risk is always relative to the information and organization; even a low-access role can do significant damage in the wrong hands.

In general, FusionAuth roles follow this convention:

However, when an entity is missing one of these roles, such as a _deleter role, the _manager role has additional capabilities.

There are a few roles which do not follow the above convention.

Admin UI Roles#

Below are all the roles available in the FusionAuth Admin UI. There is additional documentation for the user_support_manager role and the mfa_deleter role.

The user_support_manager Role#

The user_support_manager role is a role tuned for tier 1 technical support personnel and has a mix of capabilities. A user with such a role can:

The mfa_deleter Role#

The mfa_deleter role allows an administrator to remove MFA methods from users in the Admin UI without requiring a one-time code from the target user. To reduce abuse risk, this role has additional constraints:

• The target user cannot be registered to the FusionAuth admin application.
• The target user must be notifiable through at least one verified primary identity:
  • verified email + configured tenant.emailConfiguration.adminTwoFactorMethodRemoveEmailTemplateId, or
  • verified phone number + configured tenant.phoneConfiguration.adminTwoFactorMethodRemoveTemplateId.
• Users with this role removing their own MFA methods still use the standard verification code flow.

FusionAuth Tenant Manager roles#

Below are all the roles available for use in the Tenant Manager application.