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

  • Artigo

Para acessar um recurso protegido, como e-mail ou dados de 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 seu aplicativo. Compreender esses conceitos fundamentais ajudará você a criar aplicativos mais seguros e confiáveis que solicitam apenas o acesso de que precisam, quando precisam, de usuários e administradores.

Cenários de acesso

Como programador de aplicações, tem de identificar de que forma a aplicação acederá aos dados. O aplicativo pode usar acesso delegado, agindo em nome de um usuário conectado, ou acesso somente aplicativo, agindo apenas como a própria identidade do aplicativo.

Image shows illustration of access scenarios.

Acesso delegado (acesso em nome de um utilizador)

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. Tanto o cliente quanto o usuário devem ser autorizados separadamente para 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 chamadas de escopos. Escopos são permissões para um determinado recurso que representam 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 que lhe foram concedidos para acessar 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 usuário)

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

O acesso somente ao aplicativo usa funções de aplicativo em vez de escopos delegados. Quando concedidas por meio de consentimento, as funções do aplicativo também podem ser chamadas de permissões de aplicativos. O aplicativo cliente deve receber permissões de aplicativo apropriadas do aplicativo de recurso que está chamando. Uma vez 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. São permissões que permitem que a aplicação aja em nome de um utilizador. O aplicativo nunca poderá acessar nada que o próprio usuário conectado não possa acessar.

Por exemplo, pegue um aplicativo que recebeu a Files.Read.All permissão delegada em nome do usuário. O aplicativo só será capaz de 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 de aplicativo, sem a presença de um usuário conectado. O aplicativo poderá acessar todos os dados aos quais a permissão está associada.

Por exemplo, um aplicativo que recebeu a permissão Files.Read.All de aplicativo da API do Microsoft Graph poderá ler qualquer arquivo no locatário usando o Microsoft Graph. Em geral, apenas 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 aplicativos

Tipos de permissão Permissões delegadas Permissões de aplicações
Tipos de aplicações Web / Mobile / aplicativo de página única (SPA) Web/Daemon
Contexto de acesso Tenha acesso em nome de um utilizador Ter acesso sem um utilizador
Quem pode consentir - Os utilizadores podem consentir os seus dados
- Os administradores podem consentir para todos os usuários		 O administrador é o único que pode dar consentimento
Métodos de consentimento - Estática: lista configurada no registro do aplicativo
- Dinâmico: solicite permissões individuais no login		 - Static ONLY: lista configurada no registro do aplicativo
Outros nomes - Âmbitos de aplicação
- Escopos de permissão OAuth2		 - Funções do aplicativo
- Permissões somente para aplicativos
Resultado do consentimento (específico do Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Uma forma de conceder permissões às aplicações é através do 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 previamente concedido é revogado.
  • Quando o aplicativo é codificado para solicitar especificamente o consentimento durante o login.
  • Quando o aplicativo usa consentimento dinâmico para solicitar novas permissões, conforme necessário, em tempo de execução.

Os principais detalhes de um prompt de consentimento são a lista de permissões que o aplicativo requer 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 Experiência de consentimento do aplicativo.

O consentimento do usuário acontece quando um usuário tenta entrar em um aplicativo. O utilizador fornece as suas credenciais de início de sessão, que são verificadas para determinar se o consentimento já foi concedido. Se não existir nenhum registro anterior de consentimento de usuário ou administrador para as permissões necessárias, o usuário será mostrado um prompt de consentimento e 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 quem concede consentimento. Por exemplo, as permissões de aplicativo e muitas permissões delegadas de alto privilégio só podem ser consentidas por um administrador.

Os administradores podem conceder consentimento para si próprios ou para toda a organização. Para obter mais informações sobre o consentimento do usuário e do administrador, consulte Visão geral do consentimento do usuário e do administrador.

As solicitações de autenticação são solicitadas para consentimento do administrador se o consentimento não tiver 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 o 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 foram pré-autorizadas. Dessa forma, um aplicativo que tenha sido pré-autorizado não pedirá aos usuários que consintam com permissões. Os proprietários de recursos podem pré-autorizar aplicativos cliente no portal do Azure ou usando PowerShell e APIs, como o Microsoft Graph.

Consulte também