Por que ReBAC
Por que papéis e escopos não descrevem o acesso de agentes, e o que muda quando o acesso é uma relação.
O jeito mais comum de controlar acesso é dar papéis a pessoas e conferir o papel: if user.hasRole("ADMIN"). Para agentes, esse modelo quebra em três lugares.
O primeiro é a granularidade. Um papel diz o que alguém pode fazer em geral, não sobre qual objeto. "Pode abrir issues" vale para todos os repositórios. Para dizer "pode abrir issues em acme/payments", é preciso um papel por repositório, e depois um por combinação de repositório, time e ambiente. É a explosão de papéis, e com ela ninguém consegue mais responder quem tem acesso a quê.
O segundo é o tempo. Quando os papéis vão no token, o acesso fica congelado no momento da emissão. Uma revogação espera o token vencer, e o token cresce a cada papel novo.
O terceiro é o próprio agente. Um papel é dado a alguém. Um agente age por alguém. A pergunta "este agente pode, por esta pessoa?" envolve duas identidades e a relação entre elas, e um papel não tem onde guardar isso.
O acesso como relação
No ReBAC (Relationship-Based Access Control), o acesso é um conjunto de relações entre objetos, e uma decisão é a pergunta "esta relação existe?". O modelo vem do Zanzibar, o sistema de autorização do Google, e o OpenFGA é a implementação aberta que o Xokepoint usa.
Com relações, "o agente de suporte pode abrir issue em acme/payments pela alice" vira três perguntas simples, cada uma com resposta independente. Revogar uma delas não mexe nas outras. E como as relações são consultadas na hora da chamada, uma revogação vale na chamada seguinte.
O ReBAC não cobre tudo. "Só reembolsos abaixo de R$ 500" não é uma relação, é uma condição sobre um argumento. O Xokepoint avalia essas condições em CEL, no PDP (Condições).