Skip to Content
GuidesAuthorizationRoles & Permissions

Roles & Permissions (RBAC)

Auris implements role-based access control (RBAC) with a tri-state permission resolution model: permissions can be explicitly ALLOW, explicitly DENY, or INHERIT (inherit from the role’s default). User-level permission overrides take precedence over role-level permissions, enabling fine-grained exceptions without creating dedicated roles.


Permission Format

All permissions in Auris follow the action:resource pattern:

manage:users view:invoices create:tickets edit:roles approve:expenses delete:documents assign:tickets sign:interventions export:reports

The action component describes what the permission enables. Common actions: view, create, edit, delete, manage, approve, assign, export, sign, generate.

The resource component describes the entity or feature being accessed. Resources correspond to modules in your application.

There is one special permission — admin:all — which grants unrestricted access to all resources when held by a role. It is assigned to the built-in Administrator role.


Creating Roles

Via the Console

  1. Navigate to ConsoleRolesCreate Role
  2. Enter a name (e.g., Invoice Manager), optional description, and choose a color for the role badge
  3. The role is created with no permissions. Configure permissions on the role’s detail page.

Via the API

POST/api/rolesRequires: manage:roles

Create a new role. Body: { name: string, description?: string, color?: string }.

// Using the Auris Management Client const management = await createManagementClient({ ... }) const role = await management.roles.create({ name: 'Invoice Manager', description: 'Can create and view invoices but not delete them', color: '#3b82f6', })

Configuring Permissions

Permission Categories

The Console permission editor organizes permissions into 10 categories:

CategoryExample Permissions
Documentsview:invoices, create:quotes, approve:expenses, sign:interventions
Usersview:users, manage:users, import:users, export:users
Rolesview:roles, manage:roles, assign:roles
Applicationsview:applications, manage:applications, manage:api_keys
Organizationsview:organizations, manage:organizations, manage:sso_connections
Securityview:audit_logs, manage:attack_protection, view:sessions
Billingview:billing, manage:subscriptions
Integrationsview:integrations, manage:webhooks, manage:automations
Infrastructureview:monitoring, manage:devices, manage:firewalls
Supportview:tickets, create:tickets, assign:tickets, manage:sla

Setting Permissions on a Role

In the Console, each permission has a three-way toggle on the role’s detail page:

  • ALLOW — The permission is granted to users with this role
  • DENY — The permission is explicitly denied, overriding inherited ALLOW from other roles
  • INHERIT — The role neither grants nor denies this permission (default)

A user is granted a permission if any of their roles has it set to ALLOW and none of their roles has it set to DENY.

Via the API

PATCH/api/roles/:id/permissionsRequires: manage:roles

Update role permissions. Body: { permissions: { [permission: string]: 'ALLOW' | 'DENY' | 'INHERIT' } }.


Assigning Roles to Users

Roles are assigned to users in the Console (Users → [User] → Roles tab) or via API:

POST/api/users/:id/rolesRequires: manage:users

Assign one or more roles to a user. Body: { roleIds: string[] }.

DELETE/api/users/:id/roles/:roleIdRequires: manage:users

Remove a role from a user.

Users can have multiple roles. Permissions from all roles are merged. If any role has DENY for a permission, that overrides ALLOW from other roles.


User-Level Permission Overrides

Individual users can have permissions set directly, independent of their roles. User overrides take precedence over all role permissions:

  • A user-level ALLOW grants the permission even if no role grants it
  • A user-level DENY blocks the permission even if a role grants ALLOW

Console: Users → [User] → Permissions tab → Add Override

POST/api/users/:id/permission-overridesRequires: manage:users

Set a permission override for a specific user. Body: { permission: string, effect: 'ALLOW' | 'DENY' }.


Checking Permissions

Server-Side (API Routes)

Use the requirePermission() helper to enforce permissions in API routes:

// app/api/invoices/route.ts import { requirePermission } from '@auris/nextjs/server' const config = { domain: process.env.NEXT_PUBLIC_AURIS_DOMAIN!, clientId: process.env.NEXT_PUBLIC_AURIS_CLIENT_ID!, } export const GET = requirePermission('view:invoices', config, async (req, { session }) => { // Only reached if the user has view:invoices permission const invoices = await getInvoices(session.user.id) return Response.json(invoices) }) export const POST = requirePermission('create:invoices', config, async (req, { session }) => { const body = await req.json() const invoice = await createInvoice(body, session.user.id) return Response.json(invoice, { status: 201 }) })

Client-Side (React Components)

import { useCheckPermission, usePermissions } from '@auris/react' // Check a single permission function InvoiceActions() { const { allowed: canCreate, isLoading } = useCheckPermission('create:invoices') const { allowed: canDelete } = useCheckPermission('delete:invoices') if (isLoading) return null return ( <div> {canCreate && <button>New Invoice</button>} {canDelete && <button>Delete Selected</button>} </div> ) } // Check multiple permissions at once function DashboardNav() { const { has, hasAll, hasAny } = usePermissions([ 'view:invoices', 'view:quotes', 'manage:users', 'view:billing', ]) return ( <nav> {has('view:invoices') && <a href="/invoices">Invoices</a>} {has('view:quotes') && <a href="/quotes">Quotes</a>} {has('manage:users') && <a href="/users">Users</a>} {has('view:billing') && <a href="/billing">Billing</a>} {hasAll(['view:invoices', 'view:quotes']) && <a href="/documents">All Documents</a>} {hasAny(['manage:users', 'manage:roles']) && <a href="/admin">Admin</a>} </nav> ) }

Permission API

POST/api/roles/check

Check one or more permissions for the authenticated user. Body: { permissions: string[] } or { permission: string }. Returns an array of { permission, allowed } objects.

GET/api/rolesRequires: view:roles

List all roles in the tenant, including permission counts and user counts.

GET/api/roles/:idRequires: view:roles

Get a specific role including its full permission set.

DELETE/api/roles/:idRequires: manage:roles

Delete a role. Users who held this role lose the associated permissions immediately.


Permission Resolution Order

When Auris resolves whether a user has a specific permission, it follows this precedence:

  1. User-level DENY override — If present, the permission is denied. No further evaluation.
  2. User-level ALLOW override — If present (and no DENY), the permission is granted.
  3. Role permissions — If any role has ALLOW and no role has DENY, the permission is granted.
  4. Implicit deny — If no rule grants the permission, it is denied.
User Override DENY → DENIED (stops here) User Override ALLOW → ALLOWED (stops here) Any Role DENY → DENIED (stops here) Any Role ALLOW → ALLOWED No match → DENIED

Application-Scoped Permissions

Permissions can optionally be scoped to a specific application. When an applicationId is included in a permission check, Auris evaluates permissions within the context of that application — useful for multi-application tenants where roles may differ per application.

const result = await fetch('/api/roles/check', { method: 'POST', headers: { Authorization: `Bearer ${accessToken}`, 'Content-Type': 'application/json' }, body: JSON.stringify({ permissions: ['view:invoices', 'create:invoices'], applicationId: 'app-id-for-billing-app', }), })