Skip to main content

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) resolves authorization by checking the role assigned to the subject. Instead of asking "is there a path in the relationship graph" or "do the request attributes satisfy this policy," RBAC asks "what role does this subject hold, and what does that role allow."

RBAC is the right starting point when access maps cleanly to job function. Common examples: an administrator who manages the platform, a manager who oversees a team, a user who accesses their own data, a machine client that reads a shared report.

How RBAC works on SecureAuth​

On SecureAuth Connect you model roles as identity data, surface them in the token, and enforce them through policies.

  • Role as identity data. Store the role on an identity pool attribute. One attribute can hold a single role or an array of roles.
  • Role in the token. Map the role attribute into the workspace authentication context and then into an access token or ID token claim.
  • Role in the policy. Write a SecureAuth policy that reads the claim and allows or denies based on the role. Attach the policy at the level where the role matters: the application, a specific scope, or an API endpoint.

The role travels in the token, so downstream services do not need to query a role store on every request.

Example​

A SaaS platform needs three role tiers:

  • admin can create workspaces, invite users, and view billing.
  • manager can invite users and view billing but cannot create workspaces.
  • user can sign in and access their own data.

Using RBAC on SecureAuth:

  • An identity pool attribute role holds one of admin, manager, or user.
  • The workspace maps role into the authentication context and adds it to the access token as the role claim.
  • A scope-level policy on the workspaces.create scope allows only tokens where role equals admin.
  • An API-level policy on GET /billing allows tokens where role equals admin or manager.

Changing a user's role is a single attribute update. The next token carries the new role, and every attached policy picks up the change automatically.

When to use RBAC​

Reach for RBAC when access is defined by a fixed, enumerable set of functions:

  • Job-function tiers like admin, manager, user.
  • Machine-client roles like reader, writer, exporter.
  • Coarse control over features, scopes, or APIs.
  • A stable role vocabulary that changes rarely and applies broadly.

For context-driven decisions like time, location, or risk, see Policy-Based Access Control (PBAC). For object-level access defined by relationships, see Relationship-Based Access Control (ReBAC) and Fine-Grained Access (FGA).

RBAC on SecureAuth​

Add RBAC to an application in five steps:

  1. Create an identity pool and define a role attribute on its schema. Assign the attribute to each user.
  2. Configure the workspace authentication context to include the role attribute.
  3. Add a token claim that maps the authentication context attribute into the access token.
  4. Author a SecureAuth policy that checks the claim, in the visual editor or in Rego.
  5. Attach the policy where the role matters: the client application, a scope, or an API endpoint.

Combining RBAC with other models​

RBAC handles coarse role-driven access well, but most real systems layer other models on top:

  • RBAC for the coarse cut: does the role allow the action at all.
  • ReBAC or FGA for object-level access: is this specific record owned by or shared with this user.
  • PBAC for contextual overrides: require MFA at high-risk moments, or block when the request context looks wrong.

SecureAuth evaluates all three through the same policy surface, so one attached policy can combine role, relationship, and context checks.

See also​