Authorization is hard - and authorization is all too often conflated with authentication and identity. These concerns should be clearly separated. Managing "Identity and Access Management" using a single product or solution leads to problems as your software becomes more complex.
Identity has it's own complexities including integration workflows with different protocols and external identity providers. In addition, while proof of authentication from an identity system produces identity claims, possibly including role claims from that system - these "identity roles" are not typically meaningful to applications in a solution - and thus are not a good fit for authorization.
Identity is universal. Permissions are application specific. This is why the identity system should not define permissions. Instead, identity should be one of the inputs to an authorization system. The combination of identity and an application-specific policy produces the actual permissions for the application.
While there are many ways to model authorization, the concept of roles and permissions are the most prevelant. Despite the simplicity of these concepts, modeling authorization is a design-intensive activity - not to be taken lightly - that requires tools to simplify modeling and the execution of application policy.