Skip to main content
Authorization is the process of determining whether a user is allowed to perform an action on a resource. In Frontier, authorization happens after authentication (identity verification) using a powerful Role-Based Access Control (RBAC) model.

​
How Authorization Works

Frontier’s authorization system determines access based on roles assigned to users. When a request is made, the system checks whether the user has the necessary permissions through their assigned roles.

​
RBAC Model

Frontier implements Role-Based Access Control (RBAC) with the following components:
1

Permissions

Permissions define what actions can be performed on resources. They follow the format service.resource.verb (e.g., app.organization.update).
2

Roles

Roles are collections of permissions that can be assigned to users. Frontier provides predefined roles like app_organization_owner and supports custom roles.
3

Policies

Policies bind roles to principals (users, groups, service accounts) on specific resources, granting the role’s permissions to those principals.
4

Principals

Principals are entities that can be granted permissions: users, groups, or service accounts.

​
SpiceDB Integration

SpiceDB is Authzed’s open-source Google Zanzibar-inspired permission system that powers Frontier’s authorization. SpiceDB answers the fundamental authorization question: 
does <User> have <permission> on <resource>?

​
How SpiceDB Works

Permissions are defined as relationships between users and resources. The system:
  1. Defines a schema that specifies relationships between users and resources
  2. Stores relationships in SpiceDB’s data store
  3. Builds a permission graph where nodes represent users/resources and edges represent permissions
  4. Traverses the graph during permission checks to determine access
Frontier maintains the SpiceDB schema in base_schema.zed and automatically syncs it with custom permissions defined at runtime.

​
Key Concepts

​
Namespaces

Namespaces are logical containers that organize permissions and resources. Frontier uses:
  • Predefined namespaces: app/organization, app/project, app/group, app/user
  • Custom namespaces: For application-specific resources like compute/instance or storage/file

​
Permission Format

Permissions are represented in multiple formats: 
app_organization_update
potato_cart_delete
Frontier automatically converts between these formats, with the slug format (namespace_resource_action) used internally.

​
Hierarchical Permissions

Frontier supports permission inheritance:
  • Organization-level permissions cascade to projects, groups, and resources within that organization
  • Higher-level permissions include lower-level capabilities (e.g., administer includes update, get, and delete)

​
Authorization Flow

When a user attempts an action:
1

Request Initiated

User makes a request to access a resource or perform an action
2

Identity Retrieved

Frontier extracts user credentials from session, access token, or client ID/secret
3

Permission Check

Frontier queries SpiceDB to verify if the user has the required permission
4

Graph Traversal

SpiceDB traverses the permission graph, checking role bindings and relationships
5

Decision Returned

Access is granted if valid relationships exist, denied otherwise

​
Internals: Roles and Role Bindings

Frontier models authorization using two key SpiceDB objects:

​
app/role

Defines a collection of permissions. When created, Frontier establishes relations between the role and each permission: 
// Example: Organization owner role with permissions
app/role:org_owner#app_organization_delete@app/user:*
app/role:org_owner#app_organization_update@app/user:*

​
app/rolebinding

Binds a role to a principal on a resource: 
// Links the user as bearer of the role
app/rolebinding:policy123#bearer@app/user:john
// Links the role to the binding
app/rolebinding:policy123#role@app/role:org_owner
// Links the binding to the resource
app/organization:acme#granted@app/rolebinding:policy123
This design allows dynamic role creation/updates without schema changes, as roles are data rather than schema definitions.

​
Next Steps

Permissions

Learn about permission management and custom permissions

Roles

Explore predefined and custom roles

Policies

Understand policy management and role binding

Examples

See real-world authorization patterns

Build docs developers (and LLMs) love

Get started for freeTalk to us