Compartilhar via

Visão geral de permissões e consentimento da plataforma de identidade da Microsoft

Na plataforma de identidade da Microsoft, entender permissões e consentimento é crucial para o desenvolvimento de aplicativos seguros que exigem acesso aos recursos protegidos. Este artigo fornece uma visão geral dos conceitos e cenários fundamentais relacionados a permissões e consentimento, ajudando os desenvolvedores de aplicativos a solicitar as autorizações necessárias de usuários e administradores. Ao entender esses conceitos, você pode garantir que seus aplicativos solicitem apenas o acesso necessário, promovendo a confiança e a segurança.

Para acessar um recurso protegido, como dados de email ou calendário, seu aplicativo precisa da autorização do proprietário do recurso. O proprietário do recurso pode consentir ou negar a solicitação do aplicativo. Entender esses conceitos fundamentais ajuda você a criar aplicativos mais seguros e confiáveis que solicitam apenas o acesso de que precisam, quando necessário, de usuários e administradores.

Cenários de acesso

Como desenvolvedor de aplicativos, você deve identificar como seu aplicativo acessa dados. O aplicativo pode usar o acesso delegado, atuando em nome de um usuário conectado, ou o acesso somente ao aplicativo, atuando apenas como a própria identidade do aplicativo.

A imagem mostra a ilustração de cenários de acesso.

Acesso delegado (acesso em nome de um usuário)

Nesse cenário de acesso, um usuário entrou em um aplicativo cliente. O aplicativo cliente acessa o recurso em nome do usuário. O acesso delegado requer permissões delegadas. O cliente e o usuário devem ser autorizados separadamente a fazer a solicitação. Para obter mais informações sobre o cenário de acesso delegado, consulte cenário de acesso delegado.

Para o aplicativo cliente, as permissões delegadas corretas devem ser concedidas. As permissões delegadas também podem ser denominadas escopos. Escopos são permissões para um determinado recurso que representa o que um aplicativo cliente pode acessar em nome do usuário. Para obter mais informações sobre escopos, consulte escopos e permissões.

Para o usuário, a autorização depende dos privilégios concedidos ao usuário para que ele acesse o recurso. Por exemplo, o usuário pode ser autorizado a acessar recursos de diretório pelo RBAC (controle de acesso baseado em função) do Microsoft Entra ou a acessar recursos de email e calendário pelo RBAC do Exchange Online. Para obter mais informações sobre o RBAC para aplicativos, consulte RBAC para aplicativos.

Acesso somente ao aplicativo (acesso sem um usuário)

Nesse cenário de acesso, o aplicativo atua por conta própria sem nenhum usuário conectado. O acesso do aplicativo é usado em cenários como automação e backup. Esse cenário inclui aplicativos executados como serviços ou daemons em segundo plano. É apropriado quando não for desejável ter um usuário específico conectado ou quando os dados necessários não puderem ser definidos para um único usuário. Para obter mais informações sobre o cenário de acesso somente aplicativo, consulte o acesso somente aplicativo.

O acesso somente ao aplicativo usa funções de aplicativo em vez de escopos delegados. Quando concedidas por consentimento, as funções de aplicativo também podem ser chamadas de permissões de aplicativos. O aplicativo cliente deve receber as permissões de aplicativo adequadas do aplicativo de recurso que está chamando. Depois disso ser concedido, o aplicativo cliente pode acessar os dados solicitados. Para obter mais informações sobre como atribuir funções de aplicativo a aplicativos cliente, consulte Atribuindo funções de aplicativo a aplicativos.

Tipos de permissões

As Permissões delegadas são usadas no cenário de acesso delegado. Elas permitem que o aplicativo opere em nome de um usuário. O aplicativo não consegue acessar nada que o usuário conectado não pôde acessar.

Por exemplo, considere um aplicativo que recebe a Files.Read.All permissão delegada em nome do usuário. O aplicativo só pode ler arquivos que o usuário pode acessar pessoalmente.

As Permissões de aplicativo, também conhecidas como funções de aplicativo, são usadas no cenário de acesso somente ao aplicativo sem um usuário conectado presente. O aplicativo é capaz de acessar todos os dados aos quais a permissão está associada.

Por exemplo, um aplicativo ao qual foi concedida a permissão de aplicativo Files.Read.All da API do Microsoft Graph é capaz de ler qualquer arquivo no locatário usando o Microsoft Graph. Em geral, somente um administrador ou proprietário da entidade de serviço de uma API pode consentir com as permissões de aplicativo expostas por essa API.

Comparação de permissões delegadas e de aplicativo

Tipos de permissões Permissões delegadas Permissões do aplicativo
Tipos de aplicativos Web / Móvel / SPA (aplicativo de página única) Web / Daemon
Contexto de acesso Obter acesso em nome de um usuário Obter acesso sem um usuário
Quem pode consentir – Os usuários podem consentir para seus dados
– Os administradores podem consentir para todos os usuários		 Apenas o administrador pode consentir
Métodos de consentimento – Estático: lista configurada no registro do aplicativo
- Dinâmico: solicitar permissões individuais na entrada		 – SOMENTE estático: lista configurada no registro do aplicativo
Outros nomes – Escopos
– Escopos de permissão OAuth2		 – Funções de aplicativo
– Permissões somente de aplicativo
Resultado do consentimento (específico do Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Uma maneira dos aplicativos receberem permissões é por consentimento. O consentimento é um processo em que os usuários ou administradores autorizam um aplicativo a acessar um recurso protegido. Por exemplo, quando um usuário tenta entrar em um aplicativo pela primeira vez, o aplicativo pode solicitar permissão para ver o perfil do usuário e ler o conteúdo da caixa de correio do usuário. O usuário vê a lista de permissões que o aplicativo está solicitando por meio de um prompt de consentimento. Outros cenários em que os usuários podem ver um prompt de consentimento incluem:

  • Quando o consentimento concedido anteriormente é revogado.
  • Quando o aplicativo é codificado para solicitar especificamente o consentimento durante cada entrada.
  • Quando o aplicativo usa o consentimento dinâmico para solicitar novas permissões conforme necessário no tempo de execução.

Os principais detalhes de um prompt de consentimento são a lista de permissões exigidas pelo aplicativo e as informações do editor. Para obter mais informações sobre o prompt de consentimento e a experiência de consentimento para administradores e usuários finais, consulte a experiência de consentimento do aplicativo.

O consentimento do usuário ocorre quando um usuário tenta entrar em um aplicativo. O usuário fornece suas credenciais de entrada, que são verificadas para determinar se o consentimento já foi concedido. Se não houver nenhum registro anterior de consentimento do usuário ou do administrador para as permissões necessárias, será exibido para o usuário um prompt de consentimento e o mesmo será solicitado a conceder ao aplicativo as permissões solicitadas. Um administrador pode ser obrigado a conceder consentimento em nome do usuário.

Dependendo das permissões necessárias, alguns aplicativos podem exigir que um administrador seja aquele que concede consentimento. Por exemplo, as permissões de aplicativo e muitas permissões delegadas de privilégio elevado só podem ser concedidas por um administrador.

Os administradores podem consentir para si ou para toda a organização. Para obter mais informações sobre o consentimento do usuário e do administrador, confira a visão geral do consentimento do usuário e do administrador.

As solicitações de autenticação são solicitadas para consentimento do administrador caso o consentimento não tenha sido concedido e se uma dessas permissões de alto privilégio for solicitada.

As solicitações de permissão que contêm escopos de aplicativo personalizados não são consideradas de alto privilégio e, portanto, não exigem consentimento do administrador.

Pré-autorização

A pré-autorização permite que um proprietário de aplicativo de recurso conceda permissões sem exigir que os usuários vejam um prompt de consentimento para o mesmo conjunto de permissões que são pré-autenticadas. Dessa forma, um aplicativo pré-autenticado não solicita que os usuários consentam com permissões. Os proprietários de recursos podem pré-autenticar aplicativos cliente no portal do Azure ou usando o PowerShell e APIs como o Microsoft Graph.

Na maioria dos casos, os aplicativos voltados para o cliente na ID Externa do Microsoft Entra exigirão a pré-autorização, pois eles são destinados a usuários que não fazem parte da organização e que não seriam capazes de consentir com as permissões solicitadas pelo aplicativo. A pré-autorização garante que esses usuários possam acessar o aplicativo sem serem solicitados a consentir.

Outros sistemas de autorização

A estrutura de consentimento é apenas uma maneira de um aplicativo ou usuário ser autorizado a acessar recursos protegidos. Os administradores devem estar cientes de outros sistemas de autorização que podem conceder acesso a informações confidenciais. Exemplos de vários sistemas de autorização na Microsoft incluem funções internas do Microsoft Entra, RBAC do Azure, RBAC do Exchange e consentimento específico do recurso do Teams.

Veja também

  • Last updated on