The **Authorization** module decides what a signed-in user is allowed to do. Its subtitle: _"Manage roles, resources, and access control for the selected environment."_

![Authorization model](/content/console/authorization.model.png)

Each environment uses **exactly one** authorization model, and the model you pick changes which tools appear in the rail. Configuration for the other models is preserved when you switch, so experimenting is safe.

## Model

`?tab=model` — **"Authorization model"**: _"Choose how access is decided for this environment."_ Three cards, with a checkmark and **"Active model"** on the current one:

### RBAC — Role-Based Access Control (default)

_"Assign roles to users and map CRUD permissions per resource. The right default for most applications."_

- Roles & resources
- Groups
- Simple to reason about

### ABAC — Attribute-Based Access Control

_"Write policies that decide access from user, resource, and environment attributes. Evaluated by a built-in policy engine."_

- Rego policies
- Attribute-driven
- Fine control per request

### FGA — Fine-Grained Authorization

_"Model relationships between users and resources, Zanzibar-style, for relationship-based access at scale."_

- Relationship tuples
- Inherited permissions
- Scales to graphs

Click **"Use this model"** to switch. The rail immediately swaps to that model's tools.

> **Tip**
>
> Start with RBAC. Move to ABAC when decisions depend on request context
> (time of day, resource owner, tenant attributes), and to FGA when permissions
> are inherited through a graph of objects (folders, teams, nested documents).

## Analytics

`?tab=authzAnalytics` — how often access checks run and how often they deny, over the selected time range. A rising deny rate after a model change is the signal to look at.

## RBAC tools

These three tabs appear when the model is RBAC.

### Resources

`?tab=resources` — _"Manage your resources. Create new resources with optional descriptions."_

A resource is a thing you protect: `invoice`, `project`, `vault`. The table shows Resource, Slug, Description, and actions. Each resource gets an auto-generated slug (for example `vault-5a0e1c`) with a copy button — that slug is what your permission checks reference. **"Add Resource"** creates one; **"Migrate selected"** moves resources between models.

### Roles

`?tab=roles` — _"Define roles and map permissions to roles."_

The table has one column per CRUD verb: **CREATE**, **READ**, **UPDATE**, **DELETE**. Click **"Add Role"**, name the role, then tick the verbs it may perform on each resource. Empty environments read _"No roles created yet — click 'Add Role' to create your first role."_

### Groups

`?tab=groups` — _"Assign users to groups; users inherit the group's permissions."_

Groups are the practical unit for assignment: give a group its roles once, then add users to the group. The view has three sub-tabs — **Groups**, **Members**, and **Permissions** — with a count on each. The table lists Name, Slug (with copy button), Members count, Description, and a row menu. **"New Group"** creates one.

Groups are also the target of SCIM group sync: [Users > Provisioning](/docs/console/users) maps an IdP group name onto a role, so directory membership drives permissions automatically.

## ABAC tools

### Policies

`?tab=abac` — write and test Rego policies evaluated by the bundled policy engine. A policy receives the user, the resource, the action, and environment attributes, and returns an allow or deny decision. Policies are versioned per environment.

## FGA tools

### Relationships

`?tab=fga` — manage relationship tuples of the form `(user, relation, object)`, for example `user:ada is editor of doc:budget-2026`. Permissions are then derived by walking the graph, including inherited relations.

## Checking permissions from your app

Whichever model an environment uses, your application asks the same question through the AuthZEN-compatible policy decision endpoint, or through the SDK helpers. The model is a server-side detail — switching from RBAC to ABAC does not change your call sites.

See [Permissions](/docs/permissions) for the client-side API, [FGA](/docs/fga) for relationship modelling, and [AuthZEN](/docs/authzen) for the decision endpoint contract.

## Related

| Read | To learn how to |
|------|-----------------|
| [Users](/docs/console/users) | Assign roles and groups to individual users |
| [Elevate](/docs/console/elevate) | Grant a role temporarily, with approval and expiry |
| [Audit](/docs/console/audit) | Review privilege changes and access decisions |
| [Authorization concepts](/docs/concepts/authorization) | Compare RBAC, ABAC, and FGA in depth |
| [Roles & permissions](/docs/permissions) | Check permissions from application code |