Permission Management

Permission management may sound complex, but in simple terms, it is security for your resources. Once you know which resources you need to protect, you can use cidaas and the OAuth 2.0 standard to implement proper API security.

OAuth 2.0 Trustdesk 4.x Scopes · Roles · Groups

Core concepts

The three building blocks of authorization in cidaas. Start here to understand what you are assigning and to whom.

Scopes

Permissions assigned to apps (clients). Clients request them via the client_credentials flow or by passing scope in the authz request.

Roles

Permissions assigned to user accounts. A user can hold multiple roles in CIDAAS_USERS or across several groups.

Groups

Classifications such as Department or Application. Each group defines roles; a user can belong to many groups with different roles in each.

Security mechanisms

This section introduces the key mechanisms you need to understand. The following sections show you how to use them.

InterceptorValidates incoming requests, checks the token, and either continues processing or returns unauthorized. cidaas ships configurable out-of-the-box interceptors.

Offline validationValidates the token and its matching conditions locally in the interceptor, without external API calls.

Online validationValidates the token by calling the introspection endpoint remotely. Detects revoked tokens and performs group validations not available offline.

Introspection endpointAn OAuth 2.0 endpoint for online/remote validation. On success and matching conditions it returns active: true. View API

Scopes

Scopes are permissions assigned to apps (clients). Clients request them via the client_credentials flow, or for other flows by providing scope as a query parameter in the authz request. Scopes are present in the token itself — the initial request tells the system which scopes to add.

API	Description	Link to API
Get Client Credentials Token	Issues a client_credentials token. You can identify such a token by parsing it (e.g., using authkit.io) and verifying that the sub claim equals "ANONYMOUS". In the request body, provide scope with a space-separated list of scopes to include in the token.	View API
Initiate Authentication Process	Initiates the authentication process. If the user is not authenticated, they will be prompted to log in. Add scope as a query parameter with a space-separated list of scopes to include in the token.	View API

When are scopes added to the token?

Scopes are added to the token when they are:

1. Requested in the API call — either in the client_credentials flow (for non-interactive clients) or in the authz request (for interactive clients when a user authenticates)
2. Allowed by the client — the client must be configured to allow the requested scopes

Configure scopes for an app

1

Open Applications

In Trustdesk, navigate to Integrations → Applications.

2

Select the app

Open the application you want to configure.

3

Assign scopes

Assign the allowed and default scopes (scopes are defined under Scopes).

Group / role restriction

Users can belong to various groups and have multiple roles assigned to their accounts. This is a brief overview of how user accounts are structured and how to assign groups and roles via Trustdesk. For complete details, see the User Groups and Roles documentation.

Each application can restrict access to specific groups and roles, so only users who meet the configured restriction are allowed to log in.

Configure group and role restrictions

1

Create a filter

In Trustdesk, create a filter under Permission Setup → User Group Verification Filter with the required groups and roles.

2

Open the app

Navigate to Integrations → Applications and open the application you want to restrict.

3

Authentication Setup

Open the Authentication Setup tile.

4

Select the filter

Select your filter under Group Verification Filter.

By adding groups and roles, only users who meet the configured restriction will be allowed to log in. The match condition (and or or) controls whether the user must satisfy all filters or at least one. See Groups Role Restriction for details.

Learn more: Group Role Restriction — control user access during login or SSO by verifying group memberships and roles dynamically.

AuthZEN fine-grained authorization

Beyond scopes and group/role restrictions

cidaas supports the OpenID AuthZEN standard for runtime authorization decisions using Rego policies (OPA), Policy Information Points (PIP), and Relationship-Based Access Control (ReBAC).

Topic	Description
AuthZEN Authorization	Architecture, scopes, and quick start
AuthZEN Search	Who/what/which-action search, filter policies, Discovery
AuthZEN Simulation	Live vs simulation channels and version pins
ReBAC	Schema and relationship-based permissions

API	OpenAPI
Policy Management (policy-management-srv)	View API
Policy Decision (policy-decision-srv)	View API
ReBAC (rebac-srv)	View API

Group selection on login

Group selection is a cidaas feature that prompts users to choose which group context they want to use when interacting with the system.

For more details about the group selection feature, see Token Conditions and Prechecks or navigate directly to the group selection documentation. The documentation explains how to enable the feature, its conditions, use cases, and implementation details.

Why it matters for permission management

When group selection is enabled and a user specifies a group during login, that group information is added to the access token. This allows applications to make authorization decisions based on the selected group context.

Enable group selection for an app

1

Create a configuration

In Trustdesk, create a configuration under Permission Setup → Group Selection.

2

Open the app

Navigate to Integrations → Applications and open the application you want to configure.

3

Authentication Setup

Open the Authentication Setup tile.

4

Select configuration

Select your configuration under Group Selection.

Important: Token Size Considerations

Only roles are added to the access token in cidaas, not groups. This is because users can belong to many different groups, which could result in extremely large tokens. Oversized tokens can cause "Header Too Large" errors and cause requests to fail.

Implications for validation:

• Online validation (introspection): Can validate groups because it queries the server directly
• Offline validation (interceptor): Can only validate roles and groups that are present in the token itself

If you need to validate group memberships in offline validation, ensure the relevant group information is included in the token, or use online validation via the introspection endpoint.

Need Support?

Please contact us directly on our support page or reach out to cidaas support at [email protected].