A autorização determina o que uma identidade autenticada (usuário, aplicativo ou serviço) pode fazer e quais recursos ela pode acessar dentro de um sistema.

Na maioria dos sistemas, a autorização se segue à autenticação (AuthN). Depois que o sistema sabe quem você é, a autorização determina o que você tem permissão para fazer.

A autorização garante que cada identidade autenticada opere dentro de limites definidos. Sem ela, um usuário que fizesse login com sucesso (AuthN) poderia acessar todos os dados sensíveis e executar qualquer ação (falha de AuthZ). Em arquiteturas Zero Trust, as decisões sobre autorização são avaliadas de forma contínua ao longo de uma sessão, e não apenas no acesso inicial.

A autorização conecta três componentes principais:

• Usuários (identidades autenticadas)
• Permissões (direitos específicos para realizar ações, como read:Patients)
• Recursos (os ativos que estão sendo protegidos)

Controle de acesso baseado em funções (RBAC)

O RBAC é o modelo de autorização básico. Para simplificar o gerenciamento de permissões, ele atribui permissões a funções (por exemplo, Administrador, Editor, Visualizador) e, em seguida, atribui essas funções a usuários.

• Como funciona: o sistema verifica as funções atribuídas ao usuário e agrega as permissões dele para determinar se a ação solicitada é permitida.
• Quando usar: quando as permissões do usuário se alinham claramente com funções de trabalho estáticas ou com grupos (por exemplo, em um aplicativo corporativo ou administrativo típico).
• Limitação: o RBAC é menos adequado para políticas dinâmicas ou contextuais, como as baseadas em dispositivo, tempo ou localização, porque as funções são tipicamente estáticas.

Os sistemas corporativos de IAM e os ambientes em nuvem de grande escala implementam o RBAC em suas estruturas.

Controle de acesso baseado em atributos (ABAC)

O ABAC utiliza políticas dinâmicas que avaliam os atributos do usuário, do recurso e do ambiente para tomar uma decisão de acesso.

• Como funciona: o acesso é determinado por expressões de política que são avaliadas em tempo real (por exemplo, user.department == resource.department ou verificando se a hora atual está dentro do horário comercial).
• Quando usar: quando as decisões sobre autorização forem complexas, altamente contextuais ou dependerem de fatores dinâmicos (por exemplo, conceder acesso apenas a partir de um intervalo IP corporativo, permitir o acesso a documentos apenas durante o horário comercial ou exigir níveis específicos de autorização de segurança para recursos sensíveis).
• Desvantagem: introduz complexidade. A política deve ser cuidadosamente concebida e exaustivamente testada para evitar conflitos ou acessos não intencionais entre várias combinações de atributos.

Os mecanismos de políticas baseados em padrões (como o Open Policy Agent ou XACML) aplicam a política de ABAC para manter a consistência e a auditabilidade.

Controle de acesso baseado em relacionamento (ReBAC) e autorização de granularidade fina (FGA)

O ReBAC baseia a autorização nos relacionamentos e na propriedade entre um usuário e um recurso específico.

• Como funciona: o sistema verifica relacionamentos explícitos (por exemplo, "proprietário de", "compartilhado com", "membro de grupo") para conceder ou negar acesso. As implementações atuais utilizam modelagem de relacionamento baseada em grafos para navegar por cadeias de permissão complexas.
• Quando usar: em sistemas colaborativos como redes sociais ou plataformas de compartilhamento de documentos (por exemplo, “somente o proprietário da publicação pode excluí-la”, “usuários em espaços de trabalho compartilhados podem visualizar todos os documentos”).

Os sistemas de ReBAC e FGA utilizam uma infraestrutura com reconhecimento de relacionamentos e padrões de autorização baseados em grafos para modelar e consultar esses relacionamentos em grande escala. Várias implementações de código aberto (como OpenFGA e SpiceDB) tornam essa tecnologia acessível a todos os desenvolvedores.

A autorização de granularidade fina (FGA) amplia os princípios do ReBAC para permitir decisões sobre autorização com base em grafos de relacionamento complexos em grande escala. Atravessando relacionamentos por grupos, organizações e permissões aninhadas, os sistemas de FGA podem responder a perguntas como “O usuário X pode editar o documento Y?”. Esse modelo viabiliza a autorização em plataformas sociais e de colaboração em documentos, onde o acesso pode ser herdado por meio de hierarquias de pastas, associações a grupos e relações de compartilhamento.

Aplicativos baseados em API impõem autorização por meio de tokens de acesso emitidos pelo fluxo de autorização OAuth 2.0.

1. Mapeamento de autorização: após a autenticação bem-sucedida, o servidor de autorização determina as permissões concedidas ao usuário com base no modelo de AuthZ escolhido e nas políticas dinâmicas aplicáveis (por exemplo, RBAC, ABAC).
2. Emissão de token: o servidor emite um token de acesso, geralmente um JSON Web Token (JWT), que contém declarações sobre o sujeito e os escopos para os quais ele está autorizado. Também pode emitir um token opaco que requer validação por meio do endpoint de introspecção do servidor de autorização. O fluxo de autorização determina como os tokens são adquiridos e quais declarações eles contêm.
3. Aplicação de API: quando uma API recebe uma solicitação, ela valida o JWT e aplica as regras de autorização com base nas declarações contidas no token.

Essa abordagem baseada em token é sem estado. O token contém tudo o que a API precisa: contexto de autorização e uma assinatura criptográfica.

Os escopos definem as permissões que um aplicativo cliente solicita ao servidor de autorização. O servidor de autorização concede apenas os escopos para os quais o usuário deu consentimento autorizado e os inclui no token de acesso emitido.

• Quando um aplicativo solicita um token de acesso, ele especifica o escopo necessário (por exemplo, read:documents, write:documents).
• O servidor de autorização compara os escopos solicitados com as permissões reais do usuário e concede apenas o que o usuário está autorizado a conceder.
• O token de acesso emitido contém os escopos aprovados. A API valida se o token contém os escopos necessários para a operação solicitada; se ele não possuir o escopo necessário, a API negará o acesso.

As funções normalmente definem conjuntos de acesso amplos, enquanto os escopos representam permissões refinadas em nível de ação. A combinação de funções e escopos proporciona flexibilidade para as APIs.

O OpenID Connect (OIDC) estende o OAuth 2.0 porque permite a emissão de tokens de identificação para verificação da identidade do usuário e declarações de perfil, além dos escopos de autorização.

Cada endpoint de API protegido deve validar o token de acesso recebido. É preciso verificar a assinatura do token (que ajuda a garantir a integridade e a autenticidade), a expiração (declaração exp), o público (declaração aud ), o emissor (declaração iss) e as permissões necessárias (escopos ou funções). A validação adicional pode incluir a verificação do status de revogação do token, a validação da declaração nbf (Not Before) e a imposição de limites de taxa por cliente. Para JWTs, os servidores de autorização publicam chaves públicas por meio do endpoint JSON Web Key Set (JWKS) para verificação de assinatura.

A API deve retornar códigos de status HTTP específicos para comunicar o tipo de falha.

• 401 Não autorizado: significa que a autenticação falhou ou está ausente. A solicitação não possui credenciais válidas (o token está ausente, é inválido ou expirou).
  Exemplos: ausência do cabeçalho Authorization, JWT expirado, assinatura inválida.
• 403 Proibido: significa que a autorização falhou. A identidade do usuário é conhecida (autenticada), mas as permissões dele negam o acesso ao recurso ou à ação solicitada.
  Exemplos: um token válido, mas o usuário não possui a função admin para DELETE /users/:id, resultando em um escopo insuficiente para a operação solicitada.

Qual é o risco de segurança de verificações de autorização inconsistentes?

Quando a lógica de autorização está dispersa pelo código, alguns caminhos podem não conseguir aplicar as verificações necessárias, deixando vulnerabilidades que podem ser exploradas por invasores. A prática recomendada é centralizar a aplicação de autorizações por meio de middleware ou de um mecanismo de políticas. As abordagens emergentes incluem política como código (Policy-as-Code), que utiliza linguagens como Rego (Open Policy Agent), separando a lógica da autorização do código do aplicativo e permitindo testes e auditorias centralizados.

O que é o princípio do menor privilégio?

Esse princípio exige que se conceda ao usuário ou aos serviços apenas as funções e permissões mínimas necessárias para o desempenho de suas atividades, minimizando os danos potenciais decorrentes de um comprometimento de identidade. Na prática, isso significa auditorias regulares de permissões, implementação de concessões de acesso com prazo determinado e remoção de funções ou escopos não utilizados.

Quando devo usar a autenticação em vários níveis?

A autenticação em vários níveis equilibra segurança e usabilidade. Ela desafia um usuário já autenticado a fornecer fatores adicionais (como uma leitura biométrica) somente quando ele tenta uma operação de alto risco, como uma transferência bancária ou alteração da folha de pagamento. Essa abordagem também é chamada de autenticação adaptativa ou contextual.

O que é uma vulnerabilidade comum de autorização?

A Quebra de Autorização em Nível de Objeto (BOLA), também conhecida como Referência Direta Insegura a Objeto (IDOR), é uma vulnerabilidade comum. Ela ocorre quando uma API verifica a permissão geral (por exemplo, "pode ler um documento"), mas não verifica se o usuário tem acesso ao ID do recurso específico solicitado (por exemplo, "ID do documento 12345"). Essa vulnerabilidade é consistentemente classificada como API1:2023 no Top 10 de Segurança de API da OWASP. Sempre valide tanto a permissão de ação quanto o acesso no nível do recurso.

Qual é a diferença entre autorização e controle de acesso?

A autorização é um componente do controle de acesso. O controle de acesso é a disciplina de segurança mais ampla que abrange autenticação (verificação de identidade), autorização (concessão de permissões) e aplicação (garantir que as políticas sejam aplicadas). A autorização refere-se explicitamente à tomada de decisão e à aplicação das regras sobre o que uma identidade autenticada pode fazer.

Como funciona a autorização em arquiteturas de microsserviços?

Sistemas distribuídos impõem autorização em múltiplas camadas: gateway da API (granularidade ampla), malha de serviços (nível de rede) ou serviços individuais (granularidade fina). A autorização baseada em tokens usando JWTs permite a verificação sem estado em todos os serviços. No entanto, manter a consistência é um desafio. As atualizações de políticas devem chegar a todos os serviços, ao passo que as decisões baseadas em relacionamentos exigem mecanismos de políticas centralizados ou armazenamento em cache distribuído.

A autorização é um componente de uma estratégia abrangente de gerenciamento de identidade e acesso. Estruturas de autorização modernas, como OAuth 2.0 e OpenID Connect, juntamente com modelos de granularidade fina como ABAC, ReBAC e Autorização de Granularidade Fina (FGA), permitem que os desenvolvedores criem apps mais seguros e escaláveis, alinhados aos princípios Zero Trust. Para saber mais sobre autenticação, modelos de controle de acesso e boas práticas de segurança, confira a série Introdução ao IAM da Auth0.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.