Authorization

Descope provides two primary authorization approaches for your application:

• Role-Based Access Control (RBAC) - Simple, role-centric authorization using roles and permissions
• Fine-Grained Authorization (FGA) - Advanced authorization using the authz service, including ReBAC and ABAC

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a straightforward authorization model where you create roles and assign permissions to them. Users are assigned roles, and access is granted based on the permissions associated with those roles.

Roles and Permissions: All permissions must be associated with a role. Roles can have specific permissions assigned (e.g., "Admin" role with "documents:read", "documents:write" permissions) or be standalone roles without pre-defined permissions for organizational or programmatic use.

Project-Level and Tenant-Level Roles: Roles can be created at the project level (shared across all tenants) or tenant level (specific to individual tenants). This enables tenant separation, allowing users to have different permissions depending on which tenant they're signed into (e.g., "Admin" in Tenant A, "Viewer" in Tenant B).

Fine-Grained Authorization (FGA)

Fine-Grained Authorization (FGA) refers to any authorization that uses Descope's authz service (/v1/mgmt/authz/* endpoints). FGA includes:

• Relationship-Based Access Control (ReBAC) - Define permissions based on relationships between users and resources
• Attribute-Based Access Control (ABAC) - Define permissions based on user, resource, and environmental attributes

FGA provides more granular and flexible authorization than RBAC, allowing you to model complex access control scenarios with relationships, attributes, and dynamic policies.

FGA Cache

For applications using FGA, you can deploy the FGA Cache service to accelerate authorization checks by caching authorization data locally within your cluster. The FGA Cache applies to all authorization operations that use the authz service, including ReBAC and ABAC checks.

Choosing the Right Authorization Approach

When to Use RBAC

Use RBAC when you need:

• Role-based permissions: Assign specific permissions to roles (e.g., Admin role has "delete" and "modify" permissions, while Viewer role only has "read" permission)
• Tenant-specific roles: Different roles per tenant (e.g., Tenant A has "Manager" and "Employee" roles, while Tenant B has "Admin" and "User" roles)
• Simple, scalable access control: A straightforward permission model with clearly defined roles that can scale with your organization
• Easy permission management: The ability to assign and change roles without modifying individual user permissions

When to Use FGA (ReBAC or ABAC)

• Complex Relationships: When your application's access control needs to reflect complex relationships between users and resources, ReBAC offers the flexibility you require.
• Dynamic Permissions: If permissions need to change frequently based on context or user relationships, ReBAC can dynamically adjust access rights accordingly.
• Contextual Access Control: ABAC is ideal when you need to incorporate a wide range of attributes, such as user characteristics, resource types, and environmental context (e.g., time of access), to make authorization decisions.
• Fine-Grained Control: For applications that need to control access at a more granular level than roles, FGA provides the ability to define precise access control policies.

Using Both Together

You can combine RBAC and FGA in your application. For example:

• Use RBAC for basic role-based permissions (e.g., Admin, Editor, Viewer)
• Use FGA (ReBAC) for resource-specific access (e.g., "user can edit document X because they own it")
• Use FGA (ABAC) for context-based access (e.g., "user can access resource during business hours if they have Manager role")

This hybrid approach allows you to leverage the simplicity of RBAC for common cases while using FGA for more complex authorization scenarios.