Description
With the introduction of Fine-Grained Admin Permissions v2 (FGAP) in Keycloak 26.2, administrators have gained improved capabilities for managing access control across various resources. However, the current implementation of client permissions remains overly coarse. Presently, the available permission actions for clients (primarily view, manage, and map-roles*) are insufficient to support complex access control requirements commonly seen in large-scale or security-conscious environments.
Keycloak clients are central to the authorization and authentication flow. They interact with tokens, scopes, service accounts, authentication flows, and user grants. Given their sensitive and multifaceted nature, managing clients often requires dividing responsibilities among different roles or teams. The lack of granular permissions means that any user or service granted manage access to a client gains sweeping control, including sensitive operations like rotating credentials or modifying authentication behavior/flows - an access level that may be neither necessary nor appropriate for their intended role.
To enhance security, enable better delegation, and support stricter separation of duties, this feature request proposes an expansion of FGAP to introduce more granular permissions for client-related operations.
Discussion
No response
Motivation
The principle of least privilege is foundational to modern access control and security architecture. Without fine-grained controls, organizations are forced to over-provision access or develop complex workarounds, both of which introduce risk and operational overhead. In enterprise scenarios, especially within zero-trust environments or regulated sectors (e.g., finance, healthcare, government), it's critical to tightly control who can perform which operations on Keycloak clients.
For example:
- DevOps teams may need to rotate client secrets but not modify protocol mappers or service accounts.
- Token customization might be handled by a dedicated team that should not manage client grants or authentication flows.
- Auditors or support engineers might require read-only access to service account role mappings but no mutation rights.
Currently, Keycloak lacks the flexibility to enforce these distinctions. This gap hinders secure delegation and makes access control brittle, especially in multi-team or multi-tenant environments. By addressing this, Keycloak would better align with real-world enterprise security models and facilitate safer automation, delegation, and auditing.
Details
I propose the addition of the following granular client permissions under the FGAP frameworkm each governing a specific operational domain:
- rotate-credentials: Grants the ability to rotate or reset client credentials (client secret or keys). Necessary for secure credential lifecycle management without broader configuration access.
- manage-service-account: Controls management of the client’s associated service account user (e.g., setting roles, modifying credentials). Prevents privilege escalation via ungoverned service account modifications.
- configure-authentication-flows: Permits changing authentication flow bindings for the client (e.g., setting browser flow, direct grant flow). Helps isolate flow-level customization rights from general client configuration.
- manage-grants: Enables management of grants for the client.
- assign-client-scopes Allows managing the assignment of default and optional client scopes. Essential for enforcing and delegating scope-based access control.
- manage-protocol-mappers: Grants access to create, update, or remove protocol mappers. Facilitates delegation of token customization to specialized teams without exposing unrelated settings.
These permissions would ideally be surfaced both through the Admin UI and the Admin REST API, and optionally linked to realm-wide policy templates for ease of configuration. Including them as separate actions allows Keycloak administrators to create narrowly scoped admin roles tailored to specific responsibilities.
Description
With the introduction of Fine-Grained Admin Permissions v2 (FGAP) in Keycloak 26.2, administrators have gained improved capabilities for managing access control across various resources. However, the current implementation of client permissions remains overly coarse. Presently, the available permission actions for clients (primarily view, manage, and map-roles*) are insufficient to support complex access control requirements commonly seen in large-scale or security-conscious environments.
Keycloak clients are central to the authorization and authentication flow. They interact with tokens, scopes, service accounts, authentication flows, and user grants. Given their sensitive and multifaceted nature, managing clients often requires dividing responsibilities among different roles or teams. The lack of granular permissions means that any user or service granted manage access to a client gains sweeping control, including sensitive operations like rotating credentials or modifying authentication behavior/flows - an access level that may be neither necessary nor appropriate for their intended role.
To enhance security, enable better delegation, and support stricter separation of duties, this feature request proposes an expansion of FGAP to introduce more granular permissions for client-related operations.
Discussion
No response
Motivation
The principle of least privilege is foundational to modern access control and security architecture. Without fine-grained controls, organizations are forced to over-provision access or develop complex workarounds, both of which introduce risk and operational overhead. In enterprise scenarios, especially within zero-trust environments or regulated sectors (e.g., finance, healthcare, government), it's critical to tightly control who can perform which operations on Keycloak clients.
For example:
Currently, Keycloak lacks the flexibility to enforce these distinctions. This gap hinders secure delegation and makes access control brittle, especially in multi-team or multi-tenant environments. By addressing this, Keycloak would better align with real-world enterprise security models and facilitate safer automation, delegation, and auditing.
Details
I propose the addition of the following granular client permissions under the FGAP frameworkm each governing a specific operational domain:
These permissions would ideally be surfaced both through the Admin UI and the Admin REST API, and optionally linked to realm-wide policy templates for ease of configuration. Including them as separate actions allows Keycloak administrators to create narrowly scoped admin roles tailored to specific responsibilities.