Por que um escopo não é igual a uma permissão?

Muitas vezes nos confundimos quando existe a necessidade de atribuir um escopo e uma permissão. O importante é saber que há distinção sobre eles. Podemos dividir assim:

• a relação dos scopes é com a autenticação (geração credenciais);
• e a relação das permissões é com a autorização (ações e roles);

Por mais que isso seja praticado em sistemas de IAM, os dois termos não são a mesma coisa.

Scopes e Autenticação (Geração de Credenciais)

Os scopes são, de fato, intimamente ligados ao processo de autenticação e à geração de chaves de acesso (como tokens OAuth 2.0 ou, em alguns contextos, o escopo implícito em certas APIs Keys).

• Propósito: Quando um usuário ou serviço se autentica, ele pode solicitar acesso a um conjunto específico de recursos ou dados. Os scopes servem como uma solicitação de acesso granular durante a fase de autenticação/consentimento.

• Funcionamento: Ao se autenticar (por exemplo, através de um provedor de identidade como Google, Microsoft, ID Magalu, etc.), a aplicação cliente solicita ao usuário (ou ao provedor de identidade, no caso de serviços) que ele conceda um ou mais scopes. Por exemplo, uma aplicação pode solicitar o scope, profile (para acessar o perfil básico do usuário) e email (para acessar o endereço de e-mail).

• Token de Acesso: Se o usuário consentir, o servidor de autorização emitirá um token de acesso (e.g., um JWT – JSON Web Token) que contém os scopes concedidos. Este token é a "chave de acesso" que a aplicação cliente usará para interagir com os recursos protegidos.

• Implicação: O token de acesso "só sabe" que foi concedido para operar dentro dos limites dos scopes que ele carrega. Ele não carrega as permissões detalhadas em si, mas sim os "títulos" de acesso que foram autorizados durante a autenticação.

Permissões e Autorização (Controle de Ações)

As permissões estão diretamente relacionadas à autorização - que é o processo onde determina se uma entidade (usuário, serviço, aplicação) tem o direito de executar uma ação específica em um recurso específico.

• Propósito: Após a autenticação, e com o token de acesso em mãos, a aplicação cliente tenta acessar um recurso (por exemplo, criar uma instância de Virtual Machine). O servidor de recursos (ou o sistema de autorização) então verifica se a entidade ou principal* (entende-se usuário ou service account) tem a permissão para realizar a ação solicitada.

• Funcionamento: O token de acesso, que contém os claims de indentificação do principal (e.g: PID) é apresentado ao servidor de autorização para então:

  • Validar o token e extrair o PID são exemplos de atributo de identificação.

  • Verificar as permissões: O sistema verifica se o usuário/serviço, através de suas roles (papéis) ou políticas de IAM, possui as permissões necessárias para executar a ação solicitada naquele recurso específico.

• Roles: Muitas vezes, as permissões não são atribuídas diretamente aos usuários, mas sim através de roles (papéis). Uma role é um conjunto predefinido de permissões. Por exemplo, a role "Administrador de Banco de Dados" pode incluir permissões como database.read, database.write, database.delete. O usuário é atribuído a uma role e essa role concede as permissões.

Conclusão

Compreendemos que, uma entidade principal (usuário ou service account) pode acessar um determinado recurso, pois tem o scope atrelado a sua chave de autenticação - eg., acessar a API de virtual machine. Entretanto, esse mesmo principal deverá ter a permissão para uma respectiva ação - eg., criar uma instância de VM. Não é porque ele tem acesso (scope) quer dizer ele está autorizado (permissão). Então, para que o usuário possa acessar o recurso e realizar a ação, o mesmo deverá ter scope e permissão a isso, respectivamente.

Resumo

• Requisição de Scopes (Autenticação/Consentimento): A aplicação solicita ao usuário que autorize um conjunto de scopes.

• Emissão de Token (Autenticação): Após o consentimento, um token de acesso contendo esses scopes é gerado.

• Apresentação do Token (Autorização): A aplicação usa esse token para fazer requisições a recursos protegidos.

• Avaliação de Permissões (Autorização): O sistema de recursos interpreta o token, mapeia-o para permissões e verifica se essas permissões, em conjunto com as roles atribuídas ao usuário/serviço, autorizam a ação solicitada.

note

1. Um principal é uma identidade que pode ser autenticada e autorizada a acessar recursos. Ele representa quem ou o que está tentando acessar algo. Os principais podem ser usuários humanos (como funcionários) ou cargas de trabalho (como aplicativos e serviços).