...
Most Management API endpoints can be accessed by external applications by using OAuth 2.0. In this case, it is the user who is authorising the client to perform actions on the users' behalf with the user’s permissions.
In this flow, both the user and the client are responsible for the actions performed by the client. The user has to permit the client to perform actions by giving client OAuth 2.0 scopes when signing-in and authorising the client. The use of OAuth 2.0 clients is documented in the OpenID Connect and OAuth 2.0 chapter.
Management API Client access management
Management API Clients have an owner and are tied to namespaces. If the user is allowed to administer multiple namespaces, then the Management API Client may also have multiple namespaces. The namespaces can be chosen for the client in the Web UI’s Management API Client view.
Like users, also Management API Clients have permissions. The clients don't have roles or groups, but instead the permissions are directly attached to them. Permissions can be given to the client in the Web UI's Managemen Management API Client editor.
Users are only able to give others Management API Clients permissions they are having themselveshave. For example, if a user wants to give a Management API Client a permission to modify user accounts, then the prerequisite is that the user already has the permission to modify user accounts.
...
Some entities have additional more fine grained access control lists Access Control Lists (ACL). The ACLs are needed when only a subset of users or Management API Clients should be allowed to access certain objects. The ACLs in TIS can be roughly categorised into two different groups. The core functionality is very similar and the only noteworthy difference is that in some entities the ACLs are predefined and re-used and other entities have ACLs that only exist within that entity.
...